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

201–210 of 222 posts

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

#201

Post by tripdout »

otabdeveloper4 wrote: post #187
puffoflogic wrote: post #185

Earlier quoted context omitted.

Under this abuse of terminology, a pocket calculator is capable of becoming a package/dependency manager. Or any other technology which conceivably could be put to work toward the package management problem, but has not yet been adapted to that need. I concede that these statements are "true", but they fail the relevancy test of communication.

Like I said in another comment, the problem is curating the giant database that maps version numbers to commit refs. Once you pass this roadblock, the tools Nix gives you make dependency resolution a quite a bit simpler problem to solve. The next step is then realizing you actually don't need the useless legacy version numbering scheme at all, and that you wasted that effort for nothing.

Something like this maybe? https://lazamar.co.uk/nix-versions/

I'm not sure what you mean, through, by not needing the actual program versions.

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

#202

Post by Groxx »

verdverm wrote: post #137
Groxx wrote: post #128

Earlier quoted context omitted.

I really like a lot of the distribution- and safety-related decisions Go modules made. Domain names and the proxy+sumdb are wonderfully clear, flexible, and scalable, and I think we'll see copies of it in many future languages. The rest of the stuff around modules, like crippled constraints, zero control over contents (which they have changed!), and completely non-existent "x is available, upgrade" or release tooling…

> crippled constraints Do you mean ranges on dep versions? The way it is currently, the version you set is the minimum, and the algo finds the highest minimum set across all deps and uses that. If ranges were introduced, you'd end up with an NP hard problem and need a SAT solver for your deps again > Release tooling What are you looking for here? Libraries only need to push a git tag, binaries do require a bit of wor…

I'm continually confused why SAT solving is seen as a bad thing. It automatically solves common real-world problems in less than a second even in absurdly extreme cases, and a couple milliseconds normally - why would you avoid it?

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

#203

Post by mhio »

noahtallen wrote: post #195
eurasiantiger wrote: post #80

Earlier quoted context omitted.

Just use .mjs extension for your code, add extensions to your imports and everything does just work.

Except in typescript, where you have to import a file with the .js extension, despite the actual file being .ts: https://github.com/microsoft/TypeScript/issues/42151 , https://github.com/microsoft/TypeScript/issues/49083 , https://github.com/microsoft/TypeScript/issues/16577 This one issue (IMO) is preventing parts of the ecosystem from switching to esm.

How does the js extension stop a project from targeting ESM?

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

#204

Post by tstrimple »

Almost any trivial application can be trivially implemented using these build systems. People encounter their own “unique” edge cases and build their own “unique” solutions to them. Over time, all these edge cases result in a proliferation of bubble gum, duct tape and baling wire that you’ve described.

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

#205

Post by __marvin_the__ »

Izkata wrote: post #111
DemocracyFTW2 wrote: post #57

Earlier quoted context omitted.

> I don't think anyone has significant issues with pip and boy would you be wrong. I just tried to install `datasette-scraper` on my system. This didn't work because it would consistently pick up outdated versions of Django and `more-itertools` from the system's Python site-packages directory. By the way I learned to (1) install an updated version of Python that has the advantage of not being the one that the system…

> no 'virtual-env' or some such! I'm pretty sure you're manually doing the same thing virtualenv (venv in python3) does for you...

I have personally never had a problem with activating a virtualenv and `pip install`-ing inside it. Most libraries nowadays also specify minimum versions for packages (e.g., >=3.6, <4.0).

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

#207

Post by otabdeveloper4 »

tripdout wrote: post #201
otabdeveloper4 wrote: post #187

Earlier quoted context omitted.

Like I said in another comment, the problem is curating the giant database that maps version numbers to commit refs. Once you pass this roadblock, the tools Nix gives you make dependency resolution a quite a bit simpler problem to solve. The next step is then realizing you actually don't need the useless legacy version numbering scheme at all, and that you wasted that effort for nothing.

Something like this maybe? https://lazamar.co.uk/nix-versions/ I'm not sure what you mean, through, by not needing the actual program versions.

What we actually want is a content-addressable global namespace of source code. (Maybe it could be marketed as "blockchain for software" or something, lol.)

Version numbers are an attempt at content-addressing from the time when software came on floppy disks and CD-ROMs. It sorta made sense given the constraints of that technology.

Nowadays trusting git tags over git revision hashes makes no real sense. (Except that git tags are kinda shorter to type, but who cares.)

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

#208

Post by tazjin »

tremon wrote: post #190
pxc wrote: post #176

Earlier quoted context omitted.

> It's been there for 15 or 20 years. Has it? What I remember being the standard practice for customizing packages was apt-get source && sudo apt-get build-dep && vim && debuild -b fewer than 15 years ago. And it's not much like what the parent poster has in mind. It modifies the global state of your system, it requires multiple steps, it produces a different artifact than you might get in the repos at any given time…

With Nix or Guix, when a cached binary artifact for a given package is missing, you may not even notice, the fallback to building from source is so transparent. I consider this to be one of the main drawbacks of these systems -- it assumes that every machine is build-capable. I do not want compilers installed on my production servers (nor would I want my RPi to attempt to rebuild half the world because the package se…

To be fair, the whole concept of manually installing individual packages on production servers (especially when they run NixOS!) is a complete anti-pattern, so that situation wouldn't even occur during normal operation.

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

#209

Post by verdverm »

Groxx wrote: post #202
verdverm wrote: post #137

Earlier quoted context omitted.

> crippled constraints Do you mean ranges on dep versions? The way it is currently, the version you set is the minimum, and the algo finds the highest minimum set across all deps and uses that. If ranges were introduced, you'd end up with an NP hard problem and need a SAT solver for your deps again > Release tooling What are you looking for here? Libraries only need to push a git tag, binaries do require a bit of wor…

I'm continually confused why SAT solving is seen as a bad thing. It automatically solves common real-world problems in less than a second even in absurdly extreme cases, and a couple milliseconds normally - why would you avoid it?

Did I say SAT was bad?

Go's algorithm is much simpler and does not need a lockfile while still giving deterministic results. Ranged deps without a lockfile cannot. There is benefit to two people running the same command and getting the same dependency versions. Most projects do not start with a lockfile, so it is quite easy to have different versions when running getting started commands.

Another example, if I install two ranged dependencies in both orders, will I get the same final deps@version list?

Why choose SAT over simpler deterministic algos?

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

#210

Post by SuperSandro2000 »

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.

But it is a pain for a distro to upgrade a vulnerable crate dependency
Post reply on HN