Earlier quoted context omitted.
conda was great to me
conda ruined my shell and never successfully worked for me. I guess YMMV
have you tried pixi for this?
Uv is the best thing to happen to the Python ecosystem in a decade
501–510 of 1001 posts
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#502Earlier quoted context omitted.
So many times I have come onto a library or tool that would fix my problem, and then realized “oh crap, it’s in Python, I don’t want to spend few hours building a brittle environment for it only for that env to break next time I need to use it” - and went to look for a worse solution in better language.
I really don't get this. I can count on no hands the number of times I've had problems simply going "pip install cool-thing-i-found". Sure, this is just my experience, but I use Python a lot and use a lot of tools written in Python.
> pip install cool-thing-i-found
This is the entire problem. You gonna put that in a lock file or just tell your colleagues to run the same command?
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#503Earlier quoted context omitted.
I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.
That works, more or less. But now you have a requirements.txt file with 300 dependencies. Which ones do you actually care about, and which are just transitive things that your top-level deps brought along for the ride? And a year later, when GitHub's Dependabot is telling you have a security vulnerability in some package you've never heard of, do you remember if you even care about that package in the first place, or…
I always just used pip-tools. Your requirements.in is the file that is human-readable and -writable, and sets your top-level deps and the version ranges you want. requirements.txt is your lockfile that you generate from .in with pip-compile. pip-compile writes out comments specifying from where each package in requirements.txt is being required.
uv does it a lot faster and generates requirements.txts that are cross-platform, which is a nice improvement.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#504I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
There is nothing I dread more within the general context of software development, broadly , than trying to run other people's Python projects. Nothing. It's shocking that it has been so bad for so long.
I really don't understand this. I find it really easy.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#505Earlier quoted context omitted.
All of these tools are third-party and the Python core development team can't do anything to prevent people from inventing new ones. Even pip is technically at arms length; it has special support in the standard library (Python releases will vendor a wheel for it, which is designed to be able to bootstrap itself for installation[0]), but is developed separately. Standards are developed to allow existing tools to inte…
It's helpful context but still seems like a lost opportunity for python to provide the UI. It feels like every couple years we are reworking the wheel and redefining how to publish software. With python over the years i can think of pip, pipx, setuptools, easy_install, distutils, venv, conda, wheel, .egg, wheel (formats) , now uv. PHP stabilized with composer, perl with cpan , go with `go mod` and `go get` (builtin).…
> It feels like every couple years we are reworking the wheel
Almost literally: https://wheelnext.dev/
> how many ways can they be written?
It's not just a matter of how they're written. For Python specifically, build orchestration is a big deal. But also, you know, there are all the architecture ideas that make uv faster than pip. Smarter (and more generous) caching; hard-linking files where possible rather than copying them; parallel downloads (I tend to write this off but it probably does help a bit, even though the downloading process is intermingled with resolution); using multiple cores for precompiling bytecode (the one real CPU-intensive task for a large pure-Python installation).
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#506Earlier quoted context omitted.
Never underestimate cultural momentum I guess. NBA players shot long 2 pointers for decades before people realized 3 > 2. Doctors refused to wash their hands before doing procedures. There’s so many things that seem obvious in retrospect but took a long time to become accepted
People paid 100x more for their hosting when using aws cloud until they realized they never neded 99.97% uptime for their t-shirt business. Oh wait too soon. Save for post for the future.
kubernetes
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#507I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
[flagged]
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#508Earlier quoted context omitted.
Don't they publish to PyPi? What do you care what they use behind the scenes?
It isn't what they use under the scene. I refered to the interfaces of other packaging tools. I use uv and it's excellent on its own. You get a repo, it's using playwright, what do you do now ? You install all the dependencies found in the dependency descriptor then sync to create a uv descriptor. or you compose a descriptor that uv understands. It's repetitive, rather systematic so it could be automated. I should vo…
[dead]
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#509I gotta say, I feel pretty vindicated after hearing for years how Python’s tooling was just fine and you should just use virtualenv with pip and how JS must be worse, that when Python devs finally get a taste of npm/cargo/bundler in their ecosystem, they freaking love it. Because yes, npm has its issues but lock files and consistent installs are amazing
I have used pip freeze > requirements.txt pip install -r requirements.txt Way before "official" lockfile existed. Your requirements.txt becomes a lockfile, as long as you accept to not use ranges. Having this in a single tool etc why not, but I don't understand this hype, when it was basically already there.
[deleted]
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#510Earlier quoted context omitted.
On my system, Pip takes noticeable time just to start up without ultimately doing anything of importance: $ time pip install ERROR: You must give at least one requirement to install (see "pip help install") real 0m0.356s user 0m0.322s sys 0m0.036s (Huh, that's a slight improvement from before; I guess pip 25.3 is a bit better streamlined.)
lol who is using pip so much that .36s of startup time matters to them? This, if presumably uv can do nothing slightly faster, is an absolutely meaningless benefit
>who is using pip so much that .36s of startup time matters to them?