I don't know, but are we going to pretend that it would be particularly difficult to get funding for drastically simplifying and improving the tooling for one of the world's most popular programming languages? I'm not sure how Rust is doing it, but the problem is hardly insurmountable.
The PSF does have massive financial challenges. I don't know how Rust does it either, but I think there's far less general overhead due to its specificity. Python has a far broader reach, with a lot of diverse use cases to cater to.
I still run into cases where a pip install that fails due to some compile issue works fine via conda. It's still very relevant. It's pip that should be switched out for something like poetry.
poetry vs pip does very little for compilation-related install failures. Most likely the difference is whether you are getting a binary package or not, and conda's repository may have a binary package that pypi does not (but also vice-versa: nowadays pypi has decent binary packages, previously conda gained a lot of popularity because it had them while pypi generally did not, especially on windows). But the main badne…
Oh I meant that poetry could be a general replacement for pip (actually it used it in it's backend) because it does a great job managing dependencies and projects in general.
I don’t think the Python community has a culture of thinking about software engineering in a principled and systematic way like you would see in places like Haskell, Rust or Clojure communities. Pythons strength (and weakness) is an emphasis on quick scripts, data science and statistics. There’s simply not the right people with the right mindset.
Not "right" or "wrong" mindset. Just different.
If your objective is to reliably build software then it’s objectively worse.
Really the issue is python itself, it shouldn't be treating it's installs and packages as something that's linked and intertwined to the base operating system. People like to complain about node packages but never seen people have the trouble with them that they have with python.
In Python you need to deliberately mess with the system Python by running your package installer under sudo. That’s not something you do accidentally.
When dealing with the system Python you should always use the system package manager. That extends to Macs for both brew and MacPorts.
Can somebody please eli5 why it is so unanimously accepted that Python's package management is terrible? For personal projects venv + requirements.txt has never caused problems for me. For work projects we use poetry because of an assumption that we would need something better but I remain unconvinced (nothing was causing a problem for that decision to be made).
For using packages, venv + requirements.txt works, but is a bit clunky and confusing. Virtual environments are very easy to break by moving them or by updating your OS (and getting a new Python with it). Poetry is one alternative, but there are far too many options and choices to make. For building packages, there are similarly many competing options with different qualities and issues.
> Virtual environments are very easy to break by moving them
Virtual environments are cattle. Don’t treat them as pets. Just use pip freeze and recreate them elsewhere.
If we're doing anecdotal evidence, then mine is that conda is by far the worst of the main Python packaging solutions in use. The absurd slowness and incompatibility with the entire rest of the Python world are only the visible tip of that iceberg. To the best of my ability to tell, conda largely exists to make up for endemic deficiencies in Windows software distribution toolchains (not Python specific) and sadly it'…
The "absurd slowness" is gone since more than a year when it switched to using the libmamba solver.
We must be living in slightly different universes. (I'm in the Berenstain one. Things are not amazing here TBH.) I'll grant you that libmamba is faster, but we're still talking "tragicomic, leaning tragic" which is not in fact a qualitative improvement because we're still in the territory of switching to a different task while resolution, eventually, occurs.
Another poster mentioned pixi elsewhere in the thread. I'll need to look into that.
Conda: a package manager disaster that became paid license required for companies over 200 employees. It worked 5 years ago, we can no longer legally use it
I have no clue why people would use Conda The big thing to realise is that when Conda first was released it was the only packaging solution that truly treated Windows as a first class citizen and for a long time was really the only way to easily install python packages on Windows. This got it a huge following in the scientific community where many people don't have a solid programming/computer background and generall…
> it manages your entire dependency chain down to the C level in a cross platform way. I love conda, but this isn't true. You need to opt-in to a bunch of optional compiler flags to get a portable yml file, and then it can often fail on different OS's/versions anyway. I haven't done too much of this since 2021 (gave up and used containers instead) but it was a nightmare getting windows/mac builds to work correctly wi…
it was a nightmare getting windows/mac builds to work correctly
I think both statements can be true. Yes getting cross platform windows/Mac/Linux builds to work using Conda could definitely be a nightmare as you say. At the same time it was still easier with Conda than any other tool I've tried.
While `uv` works amazingly well I think a lot of people don't realize that installing packages through conda (or let's say the conda-forge ecosystem) has technical advantages compared to wheels/pypi. When you install the numpy wheel through `uv` you are likely installing a pre-compiled binary that bundles openblas inside of it. When you install numpy through conda-forge, it dynamically links against a dummy blas pack…
Is there a reason this behaviour couldn’t be implemented in uv? Is this beyond what the pyproject.toml spec supports?
Fundamentally, conda is like a linux distro (or homebrew): it is cross-language package manager designed to work with a coherent set of packages (either via the anaconda channel or conda-forge). uv is currently a different installer for PyPI, which means inheriting all the positives and negatives of it. One of the negatives is the packages are not coherent, so everything needs to be vendored in such a way as to not interfere with other packages. Unless Astral wants to pay packagers to create a parallel ecosystem, uv cannot do this.
If your objective is to reliably build software then it’s objectively worse.
Many, probably the majority, just want to build something quickly and be done, or get to the next iteration. It's a huge reason why Python is widely adopted in classrooms and for ML/AI. It's objectively better than other languages that force extra overhead on users by default.