For how popular of a language python is, at this point it’s a bad sign to me that the language has default way to manage versions and create new projects. I get having options, but options are annoying to new folk.
One of the things that frustrated me more with python, coming from R and Julia, was that the math and statistics functions weren’t default. But after learning more, and learning the math, numpy, scipy and others started yo like that, there’s different projects working on the same and you pick and choose what works better for you.
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.
For how popular of a language python is, at this point it’s a bad sign to me that the language has default way to manage versions and create new projects. I get having options, but options are annoying to new folk.
Why would it be a bad sign that the language has built in tools for common things you need to do?
I’m guessing, they meant to write “that the language has no default way”.
One of the things that frustrated me more with python, coming from R and Julia, was that the math and statistics functions weren’t default. But after learning more, and learning the math, numpy, scipy and others started yo like that, there’s different projects working on the same and you pick and choose what works better for you.
Agreed, numpy really could/should be built in.
Also pandas and matplotlib but maybe that’s just me.
-Data Nerd
But what about the pleasure of starting any project with “import pandas as pd”?
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.