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

41–50 of 222 posts

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

#41

Post by cageface »

rpigab wrote: post #24

I think package management is something so important you either have to get it right on the first released version of the language, or never release an official one at all. So if you look at C, there was basically no internet or even HTTP, so if they wanted to fetch + store dependencies from centralized repositories, it would have been difficult and then need to change a lot over the years. Python is the worst to me,…

I’ve also found it not that much harder to do scripting kinds of things in Rust vs Ruby or Python. It’s a bit of extra effort of course but having a nice self contained binary at the end is pretty handy.

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

#42

Post by junon »

rpigab wrote: post #24

I think package management is something so important you either have to get it right on the first released version of the language, or never release an official one at all. So if you look at C, there was basically no internet or even HTTP, so if they wanted to fetch + store dependencies from centralized repositories, it would have been difficult and then need to change a lot over the years. Python is the worst to me,…

I was going to disagree that Python's is the worst, but then I thought about it and.. yeah, it's up there. I think there are definitely some other ecosystems with worse package management systems but they're certainly not as mainstream as Python.

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

#43

Post by arcturus17 »

nicoburns wrote: post #30
denton-scratch wrote: post #18

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 environmen…

> Using git as a repository is just nuts. Git is privately-owned, and stuffed with all kinds of unaudited junk. Do you mean github? Git is open source and one of the few pieces of software that works in a truly distributed fashion.

> Git is privately-owned, and stuffed with all kinds of unaudited junk.

Also: what do I care that people store unaudited and insecure stuff in there?

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

#44

Post by folex »

tazjin wrote: post #31

> In contrast, we apparently have no "package management theory". We have not figured out the primitives required to express dependencies We have a good hunch. The basic theory behind Nix definitely goes in the right direction, and if we look away from all the surface-level nonsense going on in Nix, it's conceptually capable (e.g. [0]) of being a first-class language dependency manager. For this to work at scale we'd…

Yes!

I'm in a team that works on a pet prog lang for distributed systems, and we did some research of using an existing package managing systems. We've settled on NPM for now, but god I wish there would be a better generic package manager out there.

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

#45

Post by pastage »

tazjin wrote: post #31

> In contrast, we apparently have no "package management theory". We have not figured out the primitives required to express dependencies We have a good hunch. The basic theory behind Nix definitely goes in the right direction, and if we look away from all the surface-level nonsense going on in Nix, it's conceptually capable (e.g. [0]) of being a first-class language dependency manager. For this to work at scale we'd…

2) In Debian a binary package has almost always just been a cache, are we thinking about Debian packaging in completely different ways? Are you perhaps talking about the aspect of doing an "build world"[0] that bsd, Gentoo and now Nix are better at?

[0] Edit: rebuilding your dependencies if you need it and handling that seemlesly CAN be hard on Debian. Something that even Nix struggles with even if they are best in class by far. It is also completely different from the notion of compiling a program. I wonder what you consider the goal of a package system.

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

#46

Post by tsimionescu »

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.

Go package management is a mess of hacks. It doesn't even have a repository, instead relying on source control systems to do the actual work, with special hacks for each source control system to define the artifacts that can be downloaded (e.g. using Git tags with some magic format, or Perforce commit Metadata). It requires you to physically move all code to a new folder in your version control if you want to increase the major version number. It requires users of your code to update all of their import statements throughout their code whenever you move your hosting. It relies on DNS for package identity. It takes arcane magic to support multiple Go modules in the same repo.

I can go on, but it's a terrible hodge-podge of systems. It works nicely for simple cases (consuming libraries off Github), but it's awful when you go into details. And it's not even used by its creators - since Google has a monorepo and they actually use their internal universal build tool to just compile everything from source.

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

#47

Post by folex »

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.

Being in the Rust full time for last 2 or 3 years: it is quite a pain to setup a release process for big Rust workspace.

Version incrementing, packaging wasms, dancing around code generation – all doable, but not standardized.

There's a release-please to automate all that, but it's not an easy task to set it up in all of your repos.

Besides, if in addition to Rust projects, you have projects in other languages like JavaScript, then you have to do it twice and struggle with understanding all of the package management systems provided by all languages you have.

A single swiss-army-knife package manager would be amazing.

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

#48

Post by Falkon1313 »

I don't see many complaints about Free Pascal/Delphi. You want a unit? Get it, add it, use it.

No 3rd party Rube Goldberg contraption needed. No package managers or dependency resolvers, no special build tooling, no lock files. No constantly having to run updates and figure out what they broke by way of transitive dependencies. Just get what you need and use it.

I haven't, however, developed enough professionally with it to know how that plays out long-term in practice. But I'd have to imagine it would compare favorably to just about everything else nowadays. The things I've been using for the last couple of decades are all pretty abysmal in comparison.

I'd say they were a solution in search of a problem, but people have managed to create a problem to justify the solution, which really still isn't very good. At least, not nearly as good as the simple get, add, use pattern.

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

#49

Post by simiones »

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...

Java's Maven has been the nicest package management tool I've ever worked with. Apart from the fact that definitions are a bit verbose, it supported everything I've ever wanted from such a tool:

1. Clear definitions of what is an artifact that it manages, easily described in a versioned file but still separate from your source code

2. Simple support to combine internal and external sources

3. Support for interacting with other package ecosystems (you can easily write a pom.xml for any other kind of package and reference it from your Java projects)

4. Not picky about version number formats

5. Not reliant on other tools to handle any step of package management (except for compilation, of course)

6. Works at the project level and has no problems about different versions being used in different projects on the same machine (with a shared cache for efficiency)

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

#50

Post by thiht »

gwd wrote: post #4

You haven't explicitly enumerated the things about those packaging systems which seem "Rube Goldberg" to you; nor have you mentioned either Golang or Rust's package management. I'm pretty happy overall with Golang's package management, and from my little exposure to Rust's package manager, it seems fairly decent as well. Do either of them strike you as "Rube Goldberg"? What aspects, and why?

Package management in Go is weird but it works well. You just run go mod tidy from time to time and you're good. Add a module proxy if you want to prevent issues with repositories disappearing and you're gooder.
Post reply on HN