Earlier quoted context omitted.
You can still use traditional venvs with UV though, if you want.
Uh, but then you don't really need uv, right?
No, but it is insanely faster than pip.
Uv's killer feature is making ad-hoc environments easy
391–400 of 428 posts
Re: Uv's killer feature is making ad-hoc environments easy
#392Earlier quoted context omitted.
Oh wow, it actually can handle the Python executable? I didn't know that, that's great! Although it's in the article as well, it didn't click until you said it, thanks!
I would avoid using this feature! It downloads a compiled portable python binary from some random github project not from PSF. That very same github project recommends against using their binary as the compilation flags is set for portability against performance. See https://gregoryszorc.com/docs/python-build-standalone/main/
Its not from some random github project its from a trusted member of open source community. Same as other libraries you use and install.
It was used by rye before rye and uv sort of merged and is used by pipx and hatch and mise (and bazel rules_python) https://x.com/charliermarsh/status/1864042688279908459
My understanding is that the problem is that psf doesnt publish portable python binaries (I dont think they even publish any binaries for linux). Luckily theres some work being done on a pep for similar functionality from an official source but that will likely take several years. Gregory has praised the attempt and made suggestions based on his experience. https://discuss.python.org/t/pep-711-pybi-a-standard-format-...
Apparently he had less spare time for open source and since astral had been helping with a lot of the maitinence work on the project he happily transfered over ownership to themin December
https://gregoryszorc.com/blog/2024/12/03/transferring-python... https://astral.sh/blog/python-build-standalone
Re: Uv's killer feature is making ad-hoc environments easy
#393Earlier quoted context omitted.
Oh wow, it actually can handle the Python executable? I didn't know that, that's great! Although it's in the article as well, it didn't click until you said it, thanks!
I still don't understand why people want separate tooling to "handle the Python executable". All you need to do is have one base installation of each version you want, and then make your venv by running the standard library venv for that Python (e.g. `python3.x -m venv .venv`).
Lots of reasons starting. You may want many people to have the same point release.
They have early builds without needing to compile it from source and have free threading (mogul) builds. I think they might even have pro builds. Not to mention that not all district releases will have the right python release. Also people want the same tool to handle both python version and venv creation and requirement installation
Re: Uv's killer feature is making ad-hoc environments easy
#394Earlier quoted context omitted.
Valid criticisms, but the "standard" choices all work well. Nvm is the de facto standard for node version management, npm is a totally satisfactory package manager, node is the standard runtime that those other runtimes try to be compatible with, etc. Will also note that in my years of js experience I've hardly ever run into module incompatibilities. It's definitely gnarly when it happens, but wouldn't consider this…
> I've hardly ever run into module incompatibilities I'm not totally sure what you're referring to, but I've definitely had a number of issues along the lines of: - I have to use import, not require, because of some constraint of the project I'm working in - the module I'm importing absolutely needs to be required, not imported I really don't have any kind of understanding of what the fundamental issues are, just a v…
I was referring to cjs vs esm (require vs import, respectively). I suspect I was late enough to the game (and focused on browser js) such that I've mostly only used esm.
I will note that node has embraced esm, and nowadays it's frowned upon to only publish cjs packages so this problem is shrinking every day. Also cool is some of the newer runtimes support esm/cjs interop.
Re: Uv's killer feature is making ad-hoc environments easy
#395I really like uv, and it's the first package manager for a while where I haven't felt like it's a minor improvement on what I'm using but ultimately something better will come out a year or two later. I'd love if we standardized on it as a community as the de facto default, especially for new folks coming in. I personally now recommend it to nearly everyone, instead of the "welllll I use poetry but pyenv works or you…
I never used anything other than pip. I never felt the need to use anything other than pip (with virtualenv). Am I missing anything?
Yeah, I switched from pip to uv. uv seems like its almost the perfect solution for me.
it does virtualenv, it does pyenv, it does pip, so all thats managed in once place.
its much faster than pip.
its like 80% of my workflow now.
Re: Uv's killer feature is making ad-hoc environments easy
#396Earlier quoted context omitted.
This is not just a pip problem. I had the problem with anaconda a few years ago where upgrading the built in editor (spyder?) pulled versions of packages which broke my ML code, or made dependencies impossible to reconsile. It was a mess, wasting hours of time. Since then I use one pip venv for each project and just never update dependencies.
Spyder isn't built-in; IDLE comes with Python (unless you get it via Debian, at least), but is not separately upgradable (as the underlying `idlelib` is part of the standard library). If upgrading Spyder broke your environment, that's presumably because you were using the same environment that Spyder itself was in. (Spyder is also implemented in Python, as the name suggests.) However, IDEs for Python also like to try…
Thanks. I understand this a lot more now that I've learned about venvs, and I'm between VScode and emacs for editing. No longer would I install a editor which depends on the same environment as the code I want to run.
As for Spyder, it is included in the default Windows install of Anaconda (and linked to by the default Anaconda Navigator). As a new user doing package management via the GUI, it was not clear at all that Spyder was sharing dependencies with my project until things started breaking.
Anaconda was also half-baked in other ways: it broke if the Windows username contains UTF-8 characters, so I ended up creating a new Windows user just for that ML work. PITA.
Re: Uv's killer feature is making ad-hoc environments easy
#397Earlier quoted context omitted.
> "Globally" means installed with sudo. These are installed into the user folder under ~/.local/ and called a user install by pip. > It works fine until you upgrade to a new version of python, in which case you install the package again. Debian/Ubuntu doesn't want you to do either, and tell you you'll break your system if you force it (the override flag is literally named "--break-system-packages"). Hell, if you're d…
Not Debian specific. The braindead option was added by pip to scare off newbies. No one with the most basic of sysad skills is “bricked” by having to uninstall a library. Again have not experienced a conflict in over 15 years. Use the system package manager or buid yourself for tools like cmake.
Uninstalling a library - no. But I specifically mentioned trying to upgrade system Python, which is a quick way to break e.g. apt.
Re: Uv's killer feature is making ad-hoc environments easy
#398Earlier quoted context omitted.
I would avoid using this feature! It downloads a compiled portable python binary from some random github project not from PSF. That very same github project recommends against using their binary as the compilation flags is set for portability against performance. See https://gregoryszorc.com/docs/python-build-standalone/main/
Its not from some random github project its from a trusted member of open source community. Same as other libraries you use and install. It was used by rye before rye and uv sort of merged and is used by pipx and hatch and mise (and bazel rules_python) https://x.com/charliermarsh/status/1864042688279908459 My understanding is that the problem is that psf doesnt publish portable python binaries (I dont think they even…
That makes sense thanks for sharing these details
Re: Uv's killer feature is making ad-hoc environments easy
#399Earlier quoted context omitted.
It’s dual MIT and Apache licensed. Worst case, if there’s a rug pull, fork it.
Is that the entire story? If so the VCs are pretty dumb. If they kill pip, that means the people who were maintaining it disperse and forking it won't restore the ecosystem that was there before.
Yarn and pnpm didn’t kill npm. I don’t see how pip could ever be fully supplanted by uv. And if it is, that would probably mean the python foundation is stewarding it.
Re: Uv's killer feature is making ad-hoc environments easy
#400Earlier quoted context omitted.
Environment and dependency management in JS-land is even worse. Similar problems with runtime version management (need to use nvm for sanity, using built-in OS package managers seems to consistently result in tears). More package managers and interactions (corepack, npm, pnpm, yarn, bun). Bad package interop (ESM vs CJS vs UMD). More runtimes (Node, Deno, Bun, Edge). Then compound this all with the fact that JS doesn…
>Similar problems with runtime version management (need to use nvm for sanity, using built-in OS package managers seems to consistently result in tears). In practice I find this a nuisance but a small one. I wish there had been a convention that lets the correct version of Node run without me manually having to switch between them. > More package managers and interactions (corepack, npm, pnpm, yarn, bun). But they al…
> I wish there had been a convention that lets the correct version of Node run without me manually having to switch between them.
For what it's worth, I think .tool-versions is slowly starting to creep into this space.
Mise (https://mise.jdx.dev/dev-tools/) and ASDF (https://asdf-vm.com/) both support it.
Big reason I prefer ASDF to nvm/rvm/etc right now is that it just automatically adjusts my versions when I cd into a project directory.