Even as an occasional casual Python user of several years, I noticed how much simpler it is to check out new projects using uv compared to other tools. It's such a relief because I used to encounter so many weird compatibility issues with Python, I guess mostly related to global installs of runtime versions and dependencies. In the past year or so, the situation seems to have dramatically improved thanks to uv.
Interesting. I basically dont touch python unless I have too becayse the lack of tooling. How does this tooling compare to an experience like working in Go?
uv run foo.py
# creates a virtual env, reads foo.py to see httpx is a dependency, installs in the ephemeral venv then runs the script
The above is from memory typed on a phone so maybe some minor syntax issues but the point i tried to make was we can kinda emulate the convenience of statically compiled binaries a-la Go these days
I really like using UV. I introduced it at work for builds and it made everything a lot faster which was awesome. Now I can remove the other components of the build process and just use one.
I am interested in how they're going to make money eventually, but right now it's working for me.
Does anyone have an idea about how they're going to monetize?
I feel like that's the biggest question I have about Astral. I wonder what they have in the tank. All of this software is great, but I'd like to see them get some kind of benefit, if only to assure me that they'll continue to exist and make awesome software.
(And also so they'll implement the `pip download` functionality I'd like!)
Astral's focus has been to support the simplest use case, pure Python project with a standard layout. Their aim has been that most users, and especially beginners, should be able to use it with zero configuration.
As such they do not currently support C extensions, nor running arbitrary code during the build process. I imagine they will add features slowly over time, but with the continued philosophy of the simple and common cases should be zero configuration.
For Python experts who don't have special needs from a build backend I would recommend flit_core, simplest and most stable build backend, or hatching, very stable and with lots of features. While uv_build is great, it does mean that users building (but not installing) your project need to be able to run native code, rather than pure Python. But this is a pretty small edge case that for most people it won't be an issue.
I tried installing a Python project last week after years of avoiding it like the plague.
brew install didn't work, use python3 not python, no pip pre-installed, ensurepip is crashing, you need to run sudo commands to fix this, after 1hour of struggle, repo didn't work anyway. how do people work like this?
You can just use uv now, that's the whole point, it will let you install any recent version of python and you can easily handle it from there. It'll also handle dependencies and one-off scripts for which you don't want to create a whole project/venv.
By rule, you should never meddle with the globally installed python because so many packages will try to look for the system installed Python and use it, better let your package manager handle it.
They don’t. That’s a sign that the local system is severely broken, and should be rebuilt to be stable. uv will still work in that case, but you’re going to constantly hit other points of friction on a mismanaged system which will waste time.
I've been coding in Python for 10+ years but I can never really get python's tooling ecosystem. It seems that there's always a newer shiny choice. easy_install, pip, conda, virtualenv, pipenv, setup_tools, hatchling, setuptools-scm, uv, requirements.txt, pyproject.toml...
I wish python can provide an "official" solution to each problem (like in rust, there's cargo, end of story), or at lease, an official document describing the current best practice to do things.
For the last year or so, I've been trying to provide an alternative guide that stays abreast the best options and provides simple guides: https://pydevtools.com/.
Readit News
E.g.
Then on another machine: The above is from memory typed on a phone so maybe some minor syntax issues but the point i tried to make was we can kinda emulate the convenience of statically compiled binaries a-la Go these daysI am interested in how they're going to make money eventually, but right now it's working for me.
Does anyone have an idea about how they're going to monetize?
(And also so they'll implement the `pip download` functionality I'd like!)
Will it support the wide range of options setuptools does? Or maybe a build.rs equivalent - build.py, but in a sane way unlike setup.py.
As such they do not currently support C extensions, nor running arbitrary code during the build process. I imagine they will add features slowly over time, but with the continued philosophy of the simple and common cases should be zero configuration.
For Python experts who don't have special needs from a build backend I would recommend flit_core, simplest and most stable build backend, or hatching, very stable and with lots of features. While uv_build is great, it does mean that users building (but not installing) your project need to be able to run native code, rather than pure Python. But this is a pretty small edge case that for most people it won't be an issue.
By rule, you should never meddle with the globally installed python because so many packages will try to look for the system installed Python and use it, better let your package manager handle it.
They don’t. That’s a sign that the local system is severely broken, and should be rebuilt to be stable. uv will still work in that case, but you’re going to constantly hit other points of friction on a mismanaged system which will waste time.
I wish python can provide an "official" solution to each problem (like in rust, there's cargo, end of story), or at lease, an official document describing the current best practice to do things.
For the last year or so, I've been trying to provide an alternative guide that stays abreast the best options and provides simple guides: https://pydevtools.com/.
I have a policy of not replying to throwaway accounts, and decided it wasn't worth breaking in this case. But I was really tempted.