Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Conda: A package management disaster?

pyherald.com

Post reply on HN
Print view View original

221–230 of 234 posts

Re: Conda: A package management disaster?

#221

Post by fire_lake »

skeledrew wrote: post #220
fire_lake wrote: post #213

Earlier quoted context omitted.

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.

I would argue that it should be possible to make something rigorous and easy to use here. The Python model is pure incidental complexity.

Re: Conda: A package management disaster?

#222

Post by skeledrew »

fire_lake wrote: post #221
skeledrew wrote: post #220

Earlier quoted context omitted.

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.

I would argue that it should be possible to make something rigorous and easy to use here. The Python model is pure incidental complexity.

It's not an argument that so far stands in this context. Otherwise a decent amount of the languages most preferred by experienced software engineers would be used more generally by literally anyone else outside that set. And Python then would either be very different, or have far less mind share.

Also keep in mind that a) Python has been around longer than every other "popular" language, and so b) it has a lot of baggage that it has to maintain in order to avoid another 2to3 fiasco.

Re: Conda: A package management disaster?

#223

Post by sswatson »

robertlagrant wrote: post #174
LarsDu88 wrote: post #27

Earlier quoted context omitted.

Poetry is pretty slow. I think `uv` will ultimately displace it on that basis alone.

How is uv so much faster? My understanding is Poetry is slow sometimes because PyPi doesn't have all the metadata required to solve things, so it needs to download packages and then figure it out.

If I recall correctly, uv is doing some ninja stuff like guessing the part of the relevant file that is likely to contain the metadata it needs and then doing a range request to avoid downloading the whole file.

Re: Conda: A package management disaster?

#224

Post by marcosdumay »

Kwpolska wrote: post #201
marcosdumay wrote: post #160

Earlier quoted context omitted.

> For personal projects venv + requirements.txt has never caused problems for me. That means you don't use Windows. What is great. Keep not using it. But most people will have a different experience.

There are no Windows-specific issues in venv + pip. Windows can be more painful if you need to compile C extensions, but you usually don't, since most commonly used packages have had binary wheels for Windows on PyPI for many years.

Installing anything in Windows is a system-specific problem.

If a pypi package has binary dependencies, it's a pip problem on Windows, if it depends on APIs that aren't installed by default, it's a pip problem on windows, if it depends on specific versions of something that isn't in python, it's a pip problem on Windows. If it depends on some API that the implementation is provided for free, but not freely, and is full of constrains on how you can install, it's a pip problem on Windows.

Most other package managers have the exact same problems. But some of the python alternatives that people often don't understand the point were created exactly to solve those problems.

Re: Conda: A package management disaster?

#225

Post by pmarreck »

reactordev wrote: post #40
pmarreck wrote: post #36

Earlier quoted context omitted.

Nix solves it for me. Takes a bit more effort upfront, but the payoff is "Python dependency determinism," which is pretty much unachievable in any other way, so...

The answer is not Yet Another Tool In The Chain. Python community itself needs to address this. Because if they don’t then you’ll have requirements.txt, setuptools, pyproject, pip, pipx, pipenv, pyenv, venv, nix.

> The answer is not Yet Another Tool In The Chain

Normally, that would be true, but Nix has wiped out my need for homebrew, asdf, and a bunch of other tooling, so it still satisfies your requirement by leaving fewer dependencies overall instead of additional ones!

Re: Conda: A package management disaster?

#226

Post by pmarreck »

sethops1 wrote: post #121
turboponyy wrote: post #57

Earlier quoted context omitted.

The thing is, Nix is not Yet Another Tool, it is the tool.

And so was Docker before Nix

Docker is the cached output of a build that just so happened to succeed

Nix guarantees builds succeed so it doesn't need to cache the output

Re: Conda: A package management disaster?

#227

Post by osdotsystem »

anakaine wrote: post #3
orf wrote: post #2

Impossible to read on mobile, least of all because of the lack of any word breaking.

Seconded. How about we don't write a blog trashing an implementation of something when our own design is missing some very basic accessibility and ux features. Though I agree with the premise, Conda is an absolute pest when you start customising an environment with a number of packages. Dependency resolution hell.

All the articles are from the Python mailing list, like the blog selected a mail (Added the source in italics below the title)

Re: Conda: A package management disaster?

#228

Post by osdotsystem »

mdaniel wrote: post #204

I hope you read it while it was available, because the domain has expired Domain Name: pyherald.com Registry Domain ID: 2663190918_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.namesilo.com Registrar URL: https://www.namesilo.com/ Updated Date: 2024-12-21T07:00:00Z Creation Date: 2021-12-21T07:00:00Z Registrar Registration Expiration Date: 2024-12-21T07:00:00Z https://web.archive.org/web/20241220211119/https://pyhera…

Back online

Re: Conda: A package management disaster?

#230

Post by kzrdude »

setopt wrote: post #200
fire_lake wrote: post #190

Earlier quoted context omitted.

Is there a reason this behaviour couldn’t be implemented in uv? Is this beyond what the pyproject.toml spec supports?

My guess is that the difference is more that PyPI intends to be a Python package repository, and thus I don’t think you can just upload say a binary copy of MKL without accompanying Python code. It’s originally a source-based repository with binary wheels being an afterthought. (I still remember the pre-wheel nightmare `pip install numpy` used to give, when it required compiling the C/C++/Fortran pieces which often f…

Well, uv itself is just a binary wheel, with source distribution available of course. Uv uses basically no python, it's pure Rust and is still distributed using PyPI.
Post reply on HN