It does have that, the ecosystem is just really fractured and also not good.
Sort of the ‘standard’ way of managing dependencies is with Pip and a requirements.txt. By itself, that installs dependencies on your host system.
So, there’s a second tool, venv, to install them per-project, but because it’s a separate tool, it has to do some wacky things, namely it uses separate pip and python executables, which you have to specify in your IDE.
But then Pip also can’t build distributions, there’s a separate tool for that, setup.py, and it doesn’t support things like .lock-files for reproducible builds, and if I remember correctly, it doesn’t deal well with conflicting version requirements and probably various other things.
Either way, people started building a grand unified package manager to cover all these use-cases. Well, multiple people did so, separately. So, now you’ve got, among others:
Pipenv
Pip-tools
Conda
PDM
Poetry
Rye
Well, and these started creating their own methods of specifying dependencies and I believe, some of them still need to be called like a venv, but others not, so that means IDEs struggle to support all these.
Amazingly, apart from Rye, which didn’t exist back when we started that project, none of these package managers support directly depending on libraries within the same repo. You always have to tag a new version, publish it, and then you can fix your dependent code.
And yeah, that was then the other reason why this stuff didn’t work for us. We spent a considerable amount of time with symlinks and custom scripts to try to make that work.
I’m willing to believe that we fucked things up when doing that, but what makes still no sense is that everything worked when running tests from the CLI, but the IDE showed nothing but red text.
It does have that, the ecosystem is just really fractured and also not good.
Sort of the ‘standard’ way of managing dependencies is with Pip and a
requirements.txt. By itself, that installs dependencies on your host system.So, there’s a second tool, venv, to install them per-project, but because it’s a separate tool, it has to do some wacky things, namely it uses separate
pipandpythonexecutables, which you have to specify in your IDE.But then Pip also can’t build distributions, there’s a separate tool for that,
setup.py, and it doesn’t support things like .lock-files for reproducible builds, and if I remember correctly, it doesn’t deal well with conflicting version requirements and probably various other things.Either way, people started building a grand unified package manager to cover all these use-cases. Well, multiple people did so, separately. So, now you’ve got, among others:
Well, and these started creating their own methods of specifying dependencies and I believe, some of them still need to be called like a venv, but others not, so that means IDEs struggle to support all these.
Amazingly, apart from Rye, which didn’t exist back when we started that project, none of these package managers support directly depending on libraries within the same repo. You always have to tag a new version, publish it, and then you can fix your dependent code.
And yeah, that was then the other reason why this stuff didn’t work for us. We spent a considerable amount of time with symlinks and custom scripts to try to make that work.
I’m willing to believe that we fucked things up when doing that, but what makes still no sense is that everything worked when running tests from the CLI, but the IDE showed nothing but red text.
So it’s big and diverse ecosystem with multiple standards to choose between
The problem isn’t that it’s missing something like cpan, it’s that there are ten incompatible ones to choose between
Remind me not to learn python. If I get into microcontrollers I shall use their C++ like language not micropython ;)
I really like the ability to dig up code from twenty years ago and just run it