Honestly also annoying as a not-so-new folk. I just thought about this yesterday, I reasonably expect to clone a random project from the internet written Java, Rust et al, and to be able to open it in my IDE and look at it.
Meanwhile, a Python project from two years ago that I helped to build, I do not expect to be able to reasonably view in an IDE at all. I remember, we gave up trying to fix all the supposedly missing dependencies at some point…
Does python not require you to include your libraries? How can the runtime environment not tell you “you used whatever library but whatever library isn’t installed” is it then hard to find the library? Does python not have anything like perl’s cpan to consolidate all libraries? Can’t you just grep for the libraries a project calls and loop over the results adding that library to the build environment?
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.
Honestly also annoying as a not-so-new folk. I just thought about this yesterday, I reasonably expect to clone a random project from the internet written Java, Rust et al, and to be able to open it in my IDE and look at it.
Meanwhile, a Python project from two years ago that I helped to build, I do not expect to be able to reasonably view in an IDE at all. I remember, we gave up trying to fix all the supposedly missing dependencies at some point…
If the language can just break during runtime because of code indentation, I can’t really trust it
Does python not require you to include your libraries? How can the runtime environment not tell you “you used whatever library but whatever library isn’t installed” is it then hard to find the library? Does python not have anything like perl’s cpan to consolidate all libraries? Can’t you just grep for the libraries a project calls and loop over the results adding that library to the build environment?
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.