Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why does every package+module system become a Rube Goldberg machine?

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 222 posts

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#11

Post by Akronymus »

> Is it just a "law of software" that this must happen to any successful language? Or are there examples of where this it has not happened, and what can we learn from them?

Dotnet has nuget and it is quite pleasant to use in my experience. I think the big deal is having some standardized way of managing them as a layer on top. In teh dotnet case, it is having the solution pull in the nuget packages, rather than individual files. Along with having a standardized way to index available packages from each source (In this case the nuget json)

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#13

Post by Hendrikto »

ChrisRackauckas wrote: post #3

Julia and Rust seem to have package systems that are fine and manageable. I think these are really just major problems in Javascript, Python, and C/C++ (exactly the languages you mention) because the kind of widespread OSS code sharing just didn't exist to the extent it does today back when those languages were designed. People shared code through email, but didn't expect one button to pull in 200 Github repositories…

Tying package management to GitHub seems convenient in the short term, but will be the baggage of the next generation.

I cringe hard when I see projects depending on git repos, without pinning a version or commit.

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#15

Post by mschuster91 »

conor_f wrote: post #5

At least in Python's case, I think people are much too hard on the packaging system. I don't think anyone has significant issues with pip itself as opposed to the runtime it exists within. Following from this, I think that most back-end applications should try solve their messy runtime environment issues with some containerization. Java/C(++) however...

> I don't think anyone has significant issues with pip itself as opposed to the runtime it exists within.

I'm running macOS with Macports, and oh boy. For a long time, the aws and eb CLI tools had different package requirements or whatnot, and you couldn't install both of them simultaneously for whatever reason. Some stuff installs fine with the system Python, some stuff needs Macports for a specific Python version, some stuff needs root access to install itself... anything Python is a hot mess.

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#16

Post by omgtehlion »

jakewins wrote: post #6

Have you used Go or Rust package ecosystems? My experience is that the older gen languages you mention had to invent package management, made lots of understandable mistakes and now are in a backwards compat hellscape. Rust and Go built their packaging story with the benefit of lessons learned from those other systems, and in my experience the difference is night and day.

Idk about Go, but Rust’s cargo seems nice, clean yet powerful.

That was my impression some time ago.

But last week I attempted to compile a couple of (not very big) tools from cargo. And it ended up downloading hundreds of dependencies and gigabytes of packages.

Looks like node_modules.jpg all over again :(

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#17

Post by tbarone »

I'll say that on the whole it seems to be getting better with time. Most people have already mentioned Rust / Go as examples of this.

I do agree it is an issue. Doing away with node_modules completely on the last rails 7 app I worked on was the most cathartic experience of my life.

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#18

Post by denton-scratch »

It annoys me that every gee-whizz new language needs to have it's own package-management system.

There's no reason why a package-management system needs to be language-specific; dependencies are often cross-language. Hell, even some blocks of code contain more than one language.

The package-management system is responsible for deploying packages. The way a package is deployed should depend on the operating environment, not on the language. These language-specific packaging arrangements typically deploy into some private part of the file-system, organized in its own idiosyncratic way.

Using git as a repository is just nuts. Git is privately-owned, and stuffed with all kinds of unaudited junk. You can't audit everything you install by hand; so these systems force you to install unaudited code, or simply not install.

I've been using Debian derivatives for years. I appreciate having an audited repository, and an installation system that deploys code to more-or-less predictable filesystem locations.

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#19

Post by emmelaich »

> we apparently have no "package management theory"

Honestly, I'd like to have a lowest common denominator of "just dump the contents of the tar/zip archive" here.

Only check required would be to ensure you're not overwriting anything.

Dependencies and PATH management etc could be done out-of-band. That way you would not have to re-download stuff at least.

Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?

#20

Post by pjmlp »

jakewins wrote: post #6

Have you used Go or Rust package ecosystems? My experience is that the older gen languages you mention had to invent package management, made lots of understandable mistakes and now are in a backwards compat hellscape. Rust and Go built their packaging story with the benefit of lessons learned from those other systems, and in my experience the difference is night and day.

Doesn't look like it, see module drama in Go, while Rust is having an npm like ecosystem of tiny crates.

Plus none of them handle binary library distribution as some of the packing models that came before them.

Post reply on HN