I'm only familiar with Python, Javascript and Rust. It seems to me that Rust is the only one that has "solved" this problem.

I dont think there are any real Python devs who thinks dependency management is solved. However, why would you claim Javascript has a good solution? The inconsistencies between node and web dev is odd at best. Babel compilation is annoying and slow. Are we even standardized on webpack yet?

Can anyone say with a straight face that getting a new JS dev caught up on what all these different parts to compile a JS program is a solved problem?

I dont fault either Python or the JS ecosystems. As pioneers in dependency management, there was a lot of trial and error. New languages like Rust benefited from it and that's ok.

> Can anyone say with a straight face that getting a new JS dev caught up on what all these different parts to compile a JS program is a solved problem?

You are intermixing dependency management with build tools. Webpack and Babel have very little to do with dependency management.

I loosely included Babel and Webpack as part of dependency management since Python does not have a similar compile step. I don't think it is unfair since they fall into the same category of wtf when trying to get your dev environment working.

With that said, I should have included Yarn and Npm with their own problems. I can't remember how often I solved my dependency problems with rm -rf node_modules.

Python does have a compile step if your packages contain C extensions and aren't bundled into binary wheels. This shit tends to only work because of a whole lot of effort by package maintainers to make sure it compiles on a handful of supported systems, but if you aren't running such a system you get to debug a bunch of C dependency errors buried under a mile of gcc warnings and other make output.

One thing node.js got right is the module resolution logic.

Node doesn't even need something like venv since module lookup is always local.

Also no problem with dependency hell. Each dependency can have its own private dependencies, even different versions of dependencies shared by sibling modules. Tools like yarn/npm can remove duplicates across a project.

It's a lot more of a pressing concern when you have an average of 1,200 dependencies per project.

(I'm actually not sure if it is the average but my anecdotal experience is that it's an order of magnitude higher than python, and 1200 wouldn't be unusual).

That's probably quite accurate for front-end projects which pull in a ton of packages for 1. A compatibility layer wih older browsers. 2. Build tooling.

Node projects tend to have a lot smaller dependency graphs.

Yes we all learned that virtual envs are not the right way to do it. Node definitely got this portion right.

I wish Python can abandon virtual envs. This is the most annoying part of setting up a project.

How come other tools don't just replicate successful models?

That's very true. Starting fresh definitely helps.

I would not say JS solved it, but yarn (and even npm these days) seem to be superior to all python dependency management tools before pipenv. None of them had a proper lockfile, for example.

Agreed. I think pipenv had a really good start but sputtered. Poetry does look hopeful to solve the dependency resolution.

> As pioneers in dependency management

Maybe a noob question, but how come they are pioneers? Weren't there languages with package systems before Python and JS?

Actually no. As diegof79 pointed out, Perl was the first one with a centralized package management system with CPAN. Perl was first released in 1987. Python was first released in 1990. Javascript was first released in 1995. The internet was the launch pad for these open source languages, which allowed the sharing of code written in these languages.

Another thing to note is that dependencies were not that complex in the 90s. The idea of dependency management started when there was too many dependencies to manage and the existing tools could not reliably reproduce builds. My guess is that all these package use took off after the dotcom boom in 2000 and everyone started building websites with Ruby, Python and eventually Nodejs.

My first encounter with something like a package manager was CPAN for Perl... maybe they were the pioneers

.NET has it’s issues mostly due to the historical mess of frameworks, but with development converging around .NET Core things have been getting a lot better.

I think the environment system in python is a confusing design flaw that could have been avoided with project specific installations. I vastly prefer installing packages on a project-by-project basis. Python introduces dependency nightmares because two projects with different needs end up using the same central local package source unless you set up different environments. So when you install an package foo for project B, package bar might stop working for project A due a dependency on an earlier version of foo.

Hasn't it?

pypi is really the de-facto package index, Pipenv/Poetry/Conda are all venv handlers (using the standard venv tools) + dependency graph, and using pip which is standard as well.

I would call this a small set of solutions (3), and they are all sane (any will do, just pick one).

Inviting the question: why don't the core devs have a serious bakeoff and bring that functionality into the core distro?

poetry and pipenv are really just layers of abstraction of what is part of the Python core (pip, pypi, venv, wheels).

I don't even see what problems they solve, it seems like you end up with more problems using them.

pip, PyPI access, venv, and wheel have all been included for a while.

I meant poetry/pipenv.

Perhaps poetry after it matures.

In the node world I see half of projects telling you how to install it with npm and half with yarn. In Python at least pip is a standard that always works to install, even if it doesn't solve the other problems.

Unless you're in data science. Then you'll be split between conda and pip, which is worse than npm and yarn. You can always swap npm and yarn, but can't do that with conda and pip.

Those are literally equivalent though, anything you can install using yarn you can install using npm. They connect to the same registry and use the same package.json format. Also, pip is relatively recent. Before that, it was a mix of setuptools, easy_install and various manual procedures.

I wouldn't call nine years relatively recent