| > Getting deterministic behaviour out of it is. As you said, there is `pip freeze`, but also the Pipfile.lock for pipenv and the poetry.lock for poetry. > but sooner or later you'll want to upgrade something that depends on something you froze, and so then you have to unfreeze everything and hope that nothing else breaks Same for Rust with its Cargo.lock, same for JS with it's package-json.lock or yarn.lock, same for everything that lets you freeze your dependencies. EDIT: That's also what test suites and CI/CD are for. > The Python ecosystem has many options because they all suck. They let me write software, manage dependencies and virtualenvs, there is even pdm which supports the recent PEP for __pypackages__ (equivalent of node_modules) instead of a virtualenv. Can you clarify how every single one of them suck? > they still haven't managed to catch up with where Maven was 20 years ago What does Maven do to prevent the problem of upgrading frozen dependencies? > I'd argue they've actually gone backwards in some ways, e.g. including pip in newer versions of Python Care to clarify? |
You don't need to freeze your dependencies in the first place, because dependency resolution is deterministic. (In the case where you want to upgrade a transitive dependency without upgrading your direct dependency, you specificy it explicitly; if you want the latest available version, or the latest available version with the same minor number or whatever, you can run a command to populate your project file with that, but it's an explicit, visible operation).
> EDIT: That's also what test suites and CI/CD are for.
That's an admission that the dependency management isn't doing its job.
> Can you clarify how every single one of them suck?
My point is that the huge proliferation of options is not a sign that they're good, but rather the opposite. Ecosystems that have decent dependency management don't feel the need to write a new system every couple of years. Maybe PDM is finally the one that doesn't suck, but at some point after six or seven tries that all suck (and yet were always widely trumpeted as "python packaging is fixed now") my confidence is pretty low.
> > I'd argue they've actually gone backwards in some ways, e.g. including pip in newer versions of Python
> Care to clarify?
Sure. I want a single entry point that I can install on my system (via my package manager) and run to build any Python project, when realistically I'm going to be working with a bunch of projects that each have separate sets of dependencies and each require separate Python versions. Putting pip in the standard library means a) half my python installs have pip and half don't b) I have several different versions of pip installed at any given time. And so it entrenches the complexity where I have to have a separate tool like virtualenv for managing which Python version I'm using for each project as well as pip. (Which wouldn't be so bad if accidentally running pip for one project while your shell was in the virtualenv for another didn't fuck up that virtualenv, potentially permanently...).