Why is it written in Rust though? I'd prefer a pure Python solution.
Uv is the best thing to happen to the Python ecosystem in a decade
431–440 of 1001 posts
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#432Or is it a corporate grab to gain more influence in the ecosystem? I like the idea, but for profit backing is out of the question. This lesson has been learned countless times.
They plan on making money by running private package registries, rather than making money on the client. https://astral.sh/pyx
What they say today and what will the board decide to do in 6 months are 2 entirely separate things.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#433Can someone steelman the python tooling ecosystem for me? Having a new packaging / dependency manager every few years seems excessive.
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).
Java and Swift had some competition with Gradle/maven and swiftPM / cocoapods, but nothing as egregious.
file tree, dep tree, task DAG. how many ways can they be written?
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#434Earlier quoted context omitted.
Yup. I never even use activate, even though that's what you find in docs all over the place. Something about modifying my environment rubs me the wrong way. I just call ``./venv/bin/python driver.py`` (or ``./venv/bin/driver`` if you install it as a script) which is fairly self-evident, doesn't mess with your environment, and you can call into as many virtualenvs as you need to independently from one another. ``uv``…
And when you control the installation, you can install multiple python versions with `make altinstall` into the same prefix, so you don't even need to pass 'project/bin/python, you can just call 'python-project' or 'project.py' or however you like.
Yep. (Although I installed into a hierarchy within /opt, and put symlinks to the binaries in /usr/local/bin. Annoyingly, I have to specify the paths to the actual executables when making venvs, so I have a little wrapper for that as well....)
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#435Earlier 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.
I don’t get the hype either. Every time I’ve tried to use tools like pyenv or pipenv they fall down when I try to install anything that doesn’t provide wheels (GDAL), so I give up and stick to pip and virtualenv. Does uv let me install GDAL without hassle?
Pyenv's a different animal. It's meant for installing multiple Python versions at once so that you're not stuck with whatever dog your base OS happens to ship.
Pipenv tried to be what uv is, but it never did seem to work right, and it had too many weird corner cases ("why is it suddenly taking 3 hours to install packages? why it is literally impossible to get it to upgrade one single dependency and not all the others?") to ever be a contender.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#436Earlier quoted context omitted.
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.
You aren’t kidding. Especially if it’s some bioinformatics software that is just hanging out there on GitHub older than a year…
Do you think bioinformatics libs written in C++ do not have the same issues?
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#437Earlier quoted context omitted.
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.
Just stick to what's in your linux distribution and you've got no problems.
No need, run python as a container. No need to mix what's installed on the hostOS.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#438I 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.
The canonical way to do this with pip was using Constraints Files [1]. When you pollute your main requirements.txt it gets harder to see which package is an actual dependency of your project, and which ones are just sub-dependencies. Constraint files also let you not install a package if it's no longer a sub-dependency.
That being said, the uv experience is much nicer (also insanely fast).
[1] https://pip.pypa.io/en/stable/user_guide/#constraints-files
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#439I 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
To be fair, Poetry has done everything uv does for about a decade. uv is much faster, which is great, but lock files, integrated venv management, etc.
Yep, coming from poetry, uv is a pure speed increase with the same feature set.
Re: Uv is the best thing to happen to the Python ecosystem in a decade
#440I recently discovered you can use uv to run code direct from a git repo.
No need to clone/manually install packages first. E.g. `uvx --from "git+https://github.com/richstokes/meshtastic_terminal.git" meshtastic-tui`