Hacker News Reader

Comment by softfalcon | Hacker News Reader

Oh no! You've gone through dependency hell so many times you've started writing your own package management!

I'm only half kidding, this is pretty cool, but I'm also really sorry that it has come to this for you and your tooling!

View on HN

This is JS. Dependency hell is par for the course.

Genuinely curious — what language do you think has good/better package management? Every time I start a Python project, for example, there's a bunch of time and frustration spent getting pip and virtual envs working.

You didn't ask me this question, but I work in Ruby, and off the top of my head, have no complaints about Bundler. Switching Ruby versions between projects is not something that is handled natively in any way (unsurprisingly?) and I know that I've struggled a lot with `rvm`, but since switching to *env (rbenv, pyenv, nodenv) I can safely say I do not have any struggles on that front either.

You should give asdf-vm a chance. Like rbenv, but for almost everything. Switch is easy, using legacyfile support almost unnoticeable.

I feel ruby's whole problem in this space is that everyone recommends a different tool. I've used several. None are terrible. But walking into an environment and getting told everyone uses a different tool is

Rust is the golden standard. python and js are on part with each other, they just have different problems:

- tooling and dependencies are hell in js

- bootstrapping is half the battle in python (see https://bitecode.substack.com/p/relieving-your-python-packag...)

Python devs always told me npm was better than pip

As a python and node dev, I think NPM wins out just because I don't have to "activate" an environment when I want to use it. The environment is always right there where my code is.

Pip and npm are pretty much equivalent, but node_modules makes for an easier setup, while venv makes for easier tooling configuration.

I haven't had any package management troubles with .NET in over a decade.

Only times I've run into dependency issues with .NET are when a library expects certain native DLLs to already be present on the system, but that's pretty rare (and fairly easy to solve).

Especially since moving to SDK-style projects, I haven't even thought about assembly bindings in a long time. I've come to really like nuget.

They are talking about client development so none of the answers are going to compare.

You aren’t grabbing ESMs from CDNs for a Node server app. And even if you are, that’s just not a situation that’s happening outside of an ecosystem that straddles client development.

Of the three languages that I deal with semi-frequently (JS, Python, and PHP), I have by far the least trouble with PHP's package management.

composer is remarkable in that it causes very few problems in practice.

It’s an excellent package manager in a mainstream language that just does its job.

It helps that the PHP community mostly just saw PSR4 and went, yeah, that’ll do.

Meanwhile over in JS land issues are still caused because different modules use different module formats and it’s all just…fragile somehow.

Ironic give the reputation of PHP that it nailed its package manager.

I know - PHP cops a lot of flack but composer just works and has never given me any grief.

Java/Maven

Elixir’s tooling, Mix, is really great.

In my mind, anyone setting out to create a package manager, or a new language that will need one, needs to at least match the functionality of Gems/Bundler or Hex/Mix. They've been around long enough that it feels like table stakes at this point.

Mix does more than just dependencies, however I am referring the table stakes as being the more narrow scope of dependency management.

Fortran: fpm is really nice. Go: modules.

> This is JS. Dependency hell is par for the course.

Is there any programming language that does not suffer from dependency hell?

Obviously it's a matter of degree, but languages with a better standard library seem less affected by dependency hell.

> (...) but languages with a better standard library seem less affected by dependency hell.

Let's ignore the hand-waving over what "better standard library" means.

Dependency hell has zero to do with standard libraries, and is exclusively related to modularity. If your language supports third party modules that can depend on third party modules, you have dependency management. Managing dependencies so far is hell, no matter how you go about it.

Of course it's related. The more the standard library provides for you, the less you need to rely on third party dependencies.

This particular incarnation of the problem is a thing because this is actually not (standards-compliant) JS. This is a direct consequence of people infecting everything with non-standard NodeJS-isms (or NodeJS-inspired isms).

Reply on news.ycombinator.com