Classifying Python virtual environment workflows

Re:Classifying Python virtual environment workflows by brundolf on Saturday January 07, 2023 @02:14PM (#34291528)

A key thing for Node is that NPM (in addition to being first-party and having a standard manifest format) installs all dependencies in the project directory, under node_modules

People complain about node_modules, but the benefit is that every Node project on a system is isolated automatically and can re-download all of its dependencies trivially (after cleaning them, or after being checked out onto a new machine)

A Node project's system-wide dependencies are:

1. A new-enough Node installation, and

...that's it

The same is true for Go and Rust and other modern languages. Python is the odd one out.

[ Parent | on HN ]

Re:Classifying Python virtual environment workflows by melony on Saturday January 07, 2023 @04:44PM (#34293193)

Go, Rust, and JS are unique in having package management solutions that prevents the diamond dependency problem. Most other languages suffer from the same problems as python in that they cannot have more than one version of the same package globally. The dependency resolution algorithms for Ruby/Dart/Julia are all NP class and require constraint solving which often fails to find a solution if your dependencies are complex.

[ Parent | on HN ]

Re:Classifying Python virtual environment workflows by brundolf on Saturday January 07, 2023 @08:01PM (#34294879)

You can face the diamond problem in NPM, it just deals with it internally (usually by installing both versions under node_modules). But I don't see that as related to whether dependencies are project-specific or system-wide

[ Parent | on HN ]

Re:Classifying Python virtual environment workflows by DougBTX on Sunday January 08, 2023 @01:03AM (#34296513)

For what it’s worth, the Poetry version solver works in the same way as Dart’s: https://github.com/python-poetry/poetry/blob/286f4ddb70394dd...

[ Parent | on HN ]