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

151–160 of 222 posts

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

#151

Post by jnxx »

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…

And Guix has put that in an beautiful form. There are two things which make Guix special:

1. The package definitions are just a normal, battle-proven, very well defined general-purpose, functional-style supporting programming language (Scheme).

2. There is no conceptual difference between a package definition in the public Guix system, and a self-written package definition which a developers makes to build and test his own package, or to build and run a specific piece of software. The difference is equally small as between using an Emacs package, and configuring that package in ones .emacs configuration file.

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

#152

Post by hiljusti »

marcosdumay wrote: post #114
pjc50 wrote: post #103

Earlier quoted context omitted.

Debian packages can have pre/postinstall scripts that mutate the overall state of the system in arbitrary ways. This is both (a) necessary to make some thing work and (b) ruins the theoretical model.

> This is ... necessary to make some thing work Things work in NixOS without the need of any of that. So, no it is not necessary. It's a need created purely from the other directives of the Debian organization.

Not necessary, but certainly it's easier to implement and get stuff done. It starts to break down and show its cracks the larger and larger it gets, though.

The difference between almost all Linux or BSD packaging systems and nixpkgs is like the difference between dynamic and compile-time-type-checked programming languages.

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

#153

Post by yamtaddle »

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…

The reasons language-specific package managers are popular:

1) "npm install" or "go get" or what have you, works on every platform (barring bugs), while "apt install" only works on some.

2) Most platform package managers aren't good at handling multiple versions of dependencies (which, neither are many language package managers, but they're easier to sandbox away with supplemental tools than system package managers are)

3) Most platform package managers lag way behind language-specific package managers, and may also lack tons and tons of packages that are available on those.

> Git is privately-owned

Git... hub, you mean?

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

#154

Post by intrasight »

I'd think that with all the CS PhDs, there'd be some academic work in this area. I haven't gone looking.

My experience as a .Net developer has not been that it's a Rube Goldberg machine. I isolate all my projects and minimize 3rd party dependencies.

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

#155

Post by hiljusti »

rklaehn wrote: post #140

I find cargo (rust package manager) relatively pleasant to use. It's not perfect, but it also is not a constant source of confusion like sbt (scala package manger) was back when I did scala. In the long term, I think the whole notion of a "package" is obsolete. In unison https://www.unison-lang.org/ , code is just a content-addressed merkle tree. So dependencies are both more precise and more fine grained than packag…

Cargo and Leiningen are the only two build/package tools I've used that are legitimately pleasant and unobtrusive. (And Cargo is more pleasant than Leiningen but I think that's the rest of the toolchain like rustc, clippy, etc)

Correlation is not causation, but some food for thought is that Rust and Clojure are also consistently the top two languages in Stack Overflow survey "most-loved languages" lists.

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

#156

Post by warrenm »

It's far simpler than you think

It all boils down to NIHS - "not invented here syndrome"

Between developers being suspicious of anyone else's work, and their innate love to build things they'll use (your wheel is cool, I guess...but MY wheel does THIS!) ...you get a gajillion libraries that overlaps 95% of the time (but never on the 5% you "care" about)

Eons ago David Pogue wrote in his review of Word (98, I think) for the Mac, "MacWrite fit on one floppy disk and had 95% of all the features I've ever needed in a word processor. Word take a CD, and has 96% of all the features I've ever needed in a word processor."

Why is Word so big? Is it because a 'word processor' needs to be that big?

Why are there so many libraries with incredibly weird interdependencies (version 1.9.2a of this lib needs 2.1.x2 of that one, not 2.1.x3 or 2.1.g7; but if you have version 1.9.3 of this lib, you can use 2.1.x2 up through 2.1.x9 ot he other one)?

Same thing - somebody somewhere sometime somewhy decided to use that library in their own stuff, and is now forever and always bound to it (...until they refactor or rewrite a perfectly good tool that was in Scala into Haskell)

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

#157

Post by tsimionescu »

jen20 wrote: post #105
tsimionescu wrote: post #46

Earlier quoted context omitted.

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

Some of your criticism is reasonable, and I’m no fan of Go’s module system as a standalone artifact, but much of your criticism is unfounded. > 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. This is untrue. > It requires users of your code to update all of their import statements throughout their code whenever you move your hosting…

> This is untrue. [needing to move code to a new folder to increase major version]

I was indeed wrong, this is not necessary, though it is the original strong recommendation of how to do it from the original modules proposal.

Still, slightly changing the critique to say that changing major version is a big hassle, and it requires touching all of your project files, and pointing out how bizarre the official recommendation is compared to other packaging systems keeps my point intact, I believe.

> This is only true if not using a vanity URL, but is sadly often the case.

Yes, I am aware that you can buy a custom DNS and point it to your repo to release under a better name, but it is almost never done (I think the only dependency the project I work on has that does this are Google's Go protobuf bindings and several k8s.io projects).

> I don’t know what you’re calling arcane magic here, but we maintain repos at work with 6-7 go modules in without it being an issue whatsoever, and no “arcane magic” required, so I’m going to go ahead and say this is untrue too.

If you want to maintain multiple Go modules in the same git repo, and you want others to be able to download them, you need to tag commits for each module you are releasing. These tags must be formatted to match the dir path to the specific module's go.mod file (which also "conveniently" becomes part of the module name), except for the afore-mentionet vX directories if you chose to follow the Go team's recommendations for major versions. Then, for local development, you also need each go.mod to contain a REPLACE directive for each other module inside the same repo (or maybe directives in a go.work file, or who knows what else). Overall, this ends up creating lots and lots of useless tags, and is the definition of what I'd call arcane.

You'll not find the tag format in any "getting started" doc, and you'll not get any help from go mod itself if you get any of this wrong - just some "not found" style errors.

Edit: oh, and I should note: I have no idea how this is supposed to be done if your repo is not in Git, even though go modules are supposed to support other VCSs too.

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

#158

Post by Pet_Ant »

warrenm wrote: post #156

It's far simpler than you think It all boils down to NIHS - "not invented here syndrome" Between developers being suspicious of anyone else's work, and their innate love to build things they'll use (your wheel is cool, I guess...but MY wheel does THIS!) ...you get a gajillion libraries that overlaps 95% of the time (but never on the 5% you "care" about) Eons ago David Pogue wrote in his review of Word (98, I think) f…

I think the issue is how hard it is to test with a range of package versions. Maven initially supported package ranges, but that got dropped in favour of repeatable builds.

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

#159

Post by goodpoint »

tazjin wrote: post #78
pastage wrote: post #45

Earlier quoted context omitted.

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

> are we thinking about Debian packaging in completely different ways? Quite likely! The whole concept of separately building a source/binary package, and then uploading/"deploying" that binary package, already violates the notion of being "just a cache" for me. There might be a tool in Debian where I can seamlessly say "do not download this package from the repository, but build it locally" - but even if so, it woul…

> There might be a tool in Debian where I can seamlessly say "do not download this package from the repository, but build it locally" - but even if so, it would surprise me if it can give me the same guarantees as Nix

It's been there for 15 or 20 years. Also Debian has been doing reproducible builds before Nix.

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

#160

Post by hiljusti »

noloblo wrote: post #82

What about haskell cabal and stack

I appreciate Hackage and its lack of garbage, although I think the exclusivity can't scale. I also like Haskell's module system

All other aspects of Haskell package management feel unfinished, like "an exercise left to the reader." The lack of polish is astounding.

See also: "Why I Don't Code in Haskell Anymore" (https://www.youtube.com/watch?v=SPwnfSmyAGI) from TsodingDaily

Post reply on HN