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

21–30 of 222 posts

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

#21

Post by pjmlp »

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…

Because cross platform packages isn't a thing, and not everyone wants to create a package for every platform out there.

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

#22

Post by staunton »

Hendrikto wrote: post #13
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.

It's not actually tied to GitHub. If GitHub died tomorrow, they would easily be able to move on and host the packages somewhere else. There's no way to do this without hosting. Also, there is a way to pin a version or commit. Julia for example always stores the exact commit information for all packages in the "Manifest" file. There are also straightforward ways to demand certain versions and package maintainers have the opportunity to specify compatibility and requirements precisely.

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

#23

Post by xiphias2 »

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.

Npm has lots of not understandable mistakes: it should already be as good with ES6+TS as other systems. Import should just work everywhere.

We should have left Commonjs a long time ago, while keeping backwards compatibility.

At the same time what I see with the node+npm system is that everything is just ,,it just doesn't work by default''.

Having 10 other package managers doesn't work either, they are faster, but don't solve this problem.

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

#24

Post by rpigab »

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 love the language, but I hate the tooling, managing installations, packages, modules, etc.

Sometimes languages are relased with just a spec and don't want to force any choice of tool or way of doing things on you, so you just manage that yourself or create third party tools, and that's where it gets wild in every direction, but it also creates room for new ideas, innovation, which later are used in "official" modern package managers built in the language tools.

And yeah, nowadays I use Rust even for scripting stuff that would be easier to do in Python, just because I don't want to create a thousandth virtualenv, find a lib that does what I want but it's for Python<3.6 ou Python2 etc., so in the end it's easier in Rust even though some new libs require nightly builds of the toolchain.

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

#25

Post by robertlagrant »

mschuster91 wrote: post #15
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,…

While I'm trained to use venvs for everything, it would be nicer to have a flat global list of dependencies in every version required of every package, and specify allowed versions in each project, which will use what you have and/or download what's missing.

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

#26

Post by verdverm »

omgtehlion wrote: post #16
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 :(

> Idk about Go

I wrote a post highlighting Go's mod system: https://verdverm.com/go-mods/

imo, it is the best designed dependency system I know of. One of the nice things is that Go uses a shared module cache so there is only one copy on your computer when multiple projects use the same dependency@version

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

#27

Post by nicoburns »

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.

Pip has lots of issues (IMO it's one of the worst package managers):

- It installs dependencies globally by default! This makes it a massive pain to work with unless you get virtualenvs setup correctly. Which you have to remember to do every time you interact with a project.

- It doesn't use lock files by default. You have to remember to lock your dependencies.

- Packages that depend on C libraries have a tendency to fail with cryptic error messages if you don't have the library installed (which can be contrasted with node.js packages which tend to bundle the library, and will even compile it from source for you if there isn't a binary version available for your platform).

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

#28

Post by Sebb767 »

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…

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

This sounds a lot like a case of https://xkcd.com/927/ . Languages have different ways of importing and installing dependencies, trying to create a package manager over all of those is just going to end up making things even more complex, especially if you target all platforms at once.

> Using git as a repository is just nuts. Git is privately-owned, and stuffed with all kinds of unaudited junk.

Git is fully open source. Are you confusing Git and GitHub?

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

#29

Post by ChrisRackauckas »

Hendrikto wrote: post #13
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.

Julia and Rust all work with using versions tied to git tags. Package management isn't tied to Github but git: packages can live on Gitlab or BitBucket, though they generally don't and that's the choice of package developers. Because of that there are tie-ins to make Github really nice to use, but for example with Julia the only piece that is truly Github based is the fact that the General registry lives in a Github repo (https://github.com/JuliaRegistries/General), but could easily migrate to another git platform if it needed to.

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

#30

Post by nicoburns »

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.

Post reply on HN