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

231–234 of 234 posts

Re: Conda: A package management disaster?

#231

Post by robertlagrant »

sswatson wrote: post #223
robertlagrant wrote: post #174

Earlier quoted context omitted.

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.

Thanks, that makes sense. I guess Poetry could add that if they liked.

Re: Conda: A package management disaster?

#232

Post by whywhywhywhy »

theamk wrote: post #186
whywhywhywhy wrote: post #167

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.

What do you do though if you want to import code written in C++? Especially complex, dependency-heavy like CUDA/ML stuff? You can just give up and say that "The proper way to do this is to use the Nvidia CUDA toolkit to write your cuda app in C++ and then invoke it as a separate process from node" [0]. That apparently works for node, but Python wants much more. If you actually want to use high-performance native code…

>What do you do though if you want to import code written in C++? Especially complex, dependency-heavy like CUDA/ML stuff?

No other CUDA software has to put it's claws deep into the os to function. I'm not even convinced Python does, seems it just dumps all the 500-900meg DLLs into the torch folder. It's more the insistence that the libraries have to exist in this place that isn't related to the project that's the issue.

Node also handles what you're talking about without issue and without thinking it needs to be part of the operating system like Python does.

Re: Conda: A package management disaster?

#233

Post by whywhywhywhy »

rbanffy wrote: post #214
whywhywhywhy wrote: post #167

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.

I'm not talking about using the "system python" I'm talking about how Python ideologically believes it's running as system python always.

Node loads packages from a subfolder within the project, Python loads packages from somewhere else in the operating system regardless of project so we have an entire ecosystem of wrappers to deal with the nightmare of that ideological choice that Node, Rust, etc just don't need to be usable.

Re: Conda: A package management disaster?

#234

Post by int_19h »

whywhywhywhy wrote: post #233
rbanffy wrote: post #214

Earlier quoted context omitted.

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.

I'm not talking about using the "system python" I'm talking about how Python ideologically believes it's running as system python always. Node loads packages from a subfolder within the project, Python loads packages from somewhere else in the operating system regardless of project so we have an entire ecosystem of wrappers to deal with the nightmare of that ideological choice that Node, Rust, etc just don't need to…

Node is pretty much the only one that uses this model, though.
Post reply on HN