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

91–100 of 222 posts

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

#91

Post by groestl »

jonfw wrote: post #88

I am starting to see some consistency these days. I mostly work in Go, so I'm not intimately familiar with the state of the art in other languages, but it looks like most ecosystems have a tool that support this flow. A declarative (go.mod) file that always installs the same dependencies every build, a tool to update that lock file (go mod tidy), and an indication in the source that indicates how the dependency is be…

And a way to locally override a dependency to conveniently work on multiple parts at the same time (go.work)

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

#92

Post by gwbas1c »

In C#, I liked the pre-Nuget approach where you just made sure 3rd party dlls were in a location relative to source code control, (or in source code control if they were small.)

Not really "package management," but it was straightforward and worked very well... (Until you had to juggle 32/64 bit native dlls.)

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

#93

Post by mijoharas »

folex wrote: post #44
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.

Not a generic package manager, but it's probably worth calling out asdf as the generic version manager[0] (maybe you're already aware of it, but it's a generic replacement for nvm, rvm, virtualenv, *vm, which supports any language based on plugins.)

Again, maybe you're already aware of it, but I think it's a nice example of genericising a concern common to many languages which sounds similar to what you're asking for (albeit unfortunately in a slightly different space).

[0] https://github.com/asdf-vm/asdf

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

#94

Post by groestl »

simiones wrote: post #49
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…

And because of that, maven infrastructure is and has been the target of multiple build frameworks and languages.

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

#95

Post by leetrout »

groestl wrote: post #91
jonfw wrote: post #88

I am starting to see some consistency these days. I mostly work in Go, so I'm not intimately familiar with the state of the art in other languages, but it looks like most ecosystems have a tool that support this flow. A declarative (go.mod) file that always installs the same dependencies every build, a tool to update that lock file (go mod tidy), and an indication in the source that indicates how the dependency is be…

And a way to locally override a dependency to conveniently work on multiple parts at the same time (go.work)

This is Go Workspaces for those unfamiliar

https://go.dev/doc/tutorial/workspaces

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

#97

Post by anthk »

mschuster91 wrote: post #84
nine_k wrote: post #58

Earlier quoted context omitted.

System Python? Root access? Oh. That's a terrible, terrible practice. First, one never touches the system Python. It's there for OS-managed stuff and to run OS components. Then, every Python-based tool should be installed in a separate, unprivileged virtualenv, with executables symlinked where you find them appropriate (usually ~/bin or /usr/local/bin). If you find yourself ever issuing a `sudo pip install`, chances…

> First, one never touches the system Python. It's there for OS-managed stuff and to run OS components. Why would one want to not use what the system provides? Everything not provided by the OS is additional maintenance burden on myself. The 'nix world has managed just fine with OS-provided bash, perl and other runtime dependencies for decades. > Then, every Python-based tool should be installed in a separate, unpriv…

Then when your system installed Python begins to crap out your whole system down, don't ask for solutions.

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

#98

Post by anthk »

austinjp wrote: post #68
goodpoint wrote: post #10

Because most developers don't learn from other projects and redo the same mistakes. It's a form of not-invented-here syndrome and you can see it in all the comments defending their favorite language.. > we apparently have no "package management theory". Apparently. In reality there's been plenty of research - and for decades - that is not being used.

> In reality there's been plenty of research - and for decades - that is not being used. Can you link what you're referring to? Genuine request, I'm curious and keen to learn more.

Perl users have been using CPAN for decades.

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

#99

Post by dboreham »

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 and Rust don't have packages. They have tooling to pull library code from git and build it in-place to be linked into a local project. That's not (really) packaging.

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

#100

Post by silon42 »

gwbas1c wrote: post #92

In C#, I liked the pre-Nuget approach where you just made sure 3rd party dlls were in a location relative to source code control, (or in source code control if they were small.) Not really "package management," but it was straightforward and worked very well... (Until you had to juggle 32/64 bit native dlls.)

You can do that with nuget too.
Post reply on HN