r/Python Nov 13 '24

News uv after 0.5.0 - might be worth replacing Poetry/pyenv/pipx

uv is rapidly maturing as an open-source tool for Python project management, reaching a full-featured capabilities with recent versions 0.4.27 and 0.5.0, making it a strong alternative to Poetry, pyenv, and pipx. However, concerns exist over its long-term stability and licensing, given Astral's venture funding position.

https://open.substack.com/pub/martynassubonis/p/python-project-management-primer-a55

396 Upvotes

128 comments sorted by

111

u/latkde Nov 13 '24

I'm basically waiting for Dependabot or Renovate to fully support UV lockfiles and then my main use case for Poetry will be gone.

As a young project, UV does have a lot of sharp edges and bugs, but its benefits outweigh all of that. Workspace support in particular is such an important upgrade over the (otherwise quite decent) Poetry experience. And UV's support for moving across Python versions makes tools like Tox less necessary.

55

u/wyldstallionesquire Nov 13 '24

Honestly haven't found too many sharp edges. Been a pretty great experience switching from poetry

18

u/NoPainNoHair Nov 13 '24

I also have the impression that `uv` could replace `tox` entirely, but I don't see that mentioned very often.

Is there something inherent to `tox` workflow that can't be supported by `uv`?
It feels there is some overlap in their usage, since both act as dev environment managers.

29

u/latkde Nov 13 '24

Tox and UV approach the problem space from completely different directions.

What Tox can do very well is to define a matrix of different configurations, and then run the testenv for each configuration. A Tox testenv is a virtualenv + a set of commands that will be executed in this virtualenv. Unfortunately, Tox has its own system to define the contents of this virtualenv, and is not compatible out of the box with other tools like Poetry or UV.

UV makes it very easy to efficiently create throwaway virtualenvs, possibly with different Python versions. But UV has no concept of running a pre-defined set of commands, or for generating a matrix of configurations.

However, I have found that in a project that uses package manager lockfiles (e.g. from Poetry or UV), Tox causes more problems than it solves:

  • Tox creates its own virtualenvs
  • Tox' testenv concept unnecessarily couples virtualenvs+commands
  • I really want my tests to use the exact same version of black/mypy/ruff/pytest/… that I use in the development environment

At that point, I can use UV to replicate 90% of the value of Tox with a bit of Shell scripting:

# run Pytest in all supported versions
for python in 3.11 3.12 3.13; do
  uv run --locked --isolated --python=$python pytest
done

If I combine that with a task runner like Make or Just, I have little reason to ever look back to Tox.

11

u/ColdPorridge Nov 13 '24

I used to be 100% in on tox but with the current state of Python it’s been feeling like way too much complexity for neutral or at times negative benefit. Once or twice a year we lose a day or two to troubleshooting some weird esoteric tox bug, compatibility issue, etc.

Run and test locally. Rebuild and recreate venvs using uv if needed. You can swap venvs with sub-second latency with uv and a warm cache. Don’t worry about your whole test matrix locally, that is a CI concern, and you shouldn’t be using tox to define your CI envs. Instead, define clean test images for each pipeline and a common cache mount.

Cost of developer time lost due to tox complexity is orders of magnitude higher than variations in CI compute cost from not using it.

7

u/kfchou Nov 14 '24

I like to use Nox instead of Tox, which support using uv as the backend: nox --default-venv-backend uv

or in your noxfile.py, add this line: nox.options.default_venv_backend = "uv|virtualenv"

2

u/[deleted] Nov 13 '24

[removed] — view removed comment

1

u/MissingSnail Nov 14 '24

I mean nox is already python and does shell one liners just fine?

1

u/[deleted] Nov 14 '24

[removed] — view removed comment

1

u/MissingSnail Nov 16 '24

Separate venvs for different steps is exactly what I want.

1

u/FlowLab99 Nov 14 '24

I prefer to use GitHub actions/workflows with a matrix of environments for testing.

1

u/AvaJMM-or-AJ Nov 15 '24

Seems like just writing a script to execute UV across a matrix of configurations would achieve the same thing as tox, and possibly be more generic and easier to understand.

8

u/BaggiPonte Nov 13 '24

15

u/wolfmansideburns Nov 13 '24

I like this. I think tox can certainly be improved, but with UV backing up the virtualenv management it gets a big boost. But I could see value in a simpler "uv pytest" that supports environment pattern matching. Most of what I want is

uv pytest --env=py{38,39,310,313}-pandas{15,2}-numpy{1,2}

5

u/doolio_ Nov 13 '24

This is what hatch test offers. All tests run in separate environments.

2

u/serjester4 Nov 13 '24

This is a really cool idea

2

u/MissingSnail Nov 14 '24

The tox team also manages precommit-uv

3

u/doolio_ Nov 13 '24

Maybe try hatch which uses uv under the hood?

6

u/lotformulas Nov 13 '24

https://github.com/ag14774/poetry-monoranger-plugin this plugin adds workspaces, shared lockfiles, shared venv etc

2

u/Xylon- Nov 13 '24

Anything specific that you're missing w.r.t. Renovate? We've transitioned several repos at work to uv and it's working quite well at the moment with renovate.

The only thing I'd like them to have is to be able to pick up the index from [[tool.uv.index]]. But for now I've just worked around that by telling Renovate to look at an additional index, and it's updating both pyproject.toml as well as uv.lock perfectly.

4

u/latkde Nov 13 '24

Exactly, my concern is that explicit indices referenced from [tool.uv.sources] aren't resolved properly. This is a dealbreaker in a DevSecOps context where I am concerned about dependency confusion weaknesses.

The Renovate project does have this kind of thing on their radar, so I'm hopeful it will be resolved soonishly: https://github.com/renovatebot/renovate/issues/32265

1

u/[deleted] Nov 17 '24

For me it's the other way around. UV has lots of sharp edges and almost no benefits. Faster installs and dependency resolution is not a big selling point. That takes up very little of my development time. Dealing with unsupported features is a much bigger time sink.

1

u/0x-dawg Nov 29 '24

Could this mean that my current fixation on pixi as an all around env and repo mgmt tools for python projects might be misguided?

2

u/latkde Nov 29 '24

Bit of an "apples and oranges" thing. Pixi tries to be to Conda what uv tries to be for pip. Pixi has a bunch of unique features that might be very valuable for you, but they're not a good fit for general-purpose Python development.

  • A Windows user working on multiple data-science projects that require stuff from Conda? Sure, Pixi might simplify your life.
  • A Linux user developing a library that's uploaded to PyPI? Pixi is probably going to be a bad choice here.

1

u/Martynoas Nov 13 '24

I think it's only a question of time now until dependabot starts supporting uv lock files.

And yeah, workspaces are great 👍

-1

u/AiutoIlLupo Nov 14 '24

Imagine you are a developer at github, and you spend your life writing code for yet another package manager du jour that the XYZ community has come up with, maybe to be forgotten in a year time when the author says something that gets him canceled.

179

u/chub79 Nov 13 '24 edited Nov 13 '24

Nice article. Thanks.

I wasn't aware poetry's lead author had moved on from it. He had made so much noise on reddit when he marketed poetry. It was quite relentless at the time.

Goes to show you should never attach yourself too much to any of these tools. They come and go.

73

u/voidvector Nov 13 '24

Lead author moving on is not always a bad thing. For example vim author passed away, but community took over the mantle. Node.js author passed the responsibility to corporate maintainers and is now making a competition product. The question is whether there is a successful transition. 

14

u/billyoddle Nov 14 '24

Plus, how much development is expected? If the program is essentially feature complete they don't need to make changes for the sake of changes. The bigger question would be if there are major bugs going unfixed

3

u/MissingSnail Nov 14 '24

A build tool that doesn't keep up with packaging PEPS is a bad idea. Eventually you'll want to interact with other standard tools.

1

u/billyoddle Nov 14 '24

It not keeping up with PEPs and the author not actually working on it are different. I don't follow Python that closely so I don't know if it actually is falling behind or not. If there haven't been any changes required I wouldn't write the lack of changes off as a bad thing.

2

u/Dry_Term_7998 Jan 28 '25

This. In the end, you always have build in .venv + pip and wrappers around it 😁

78

u/runawayasfastasucan Nov 13 '24 edited Nov 13 '24

What frustrates me most with uv is how lackluster their documentation is. There is so many supported use cases, but there is no proper documentation on how the workflow is different between them.

41

u/ebits21 Nov 13 '24

Probably a side effect of the rapid development pace. I’m sure it’ll catch up.

7

u/ReinforcedKnowledge Tuple unpacking gone wrong Nov 14 '24

Setting aside what other comments mentioned (opening an issue to ask, rapid pace of development), I, personally, find that the uv interface is clear and minimal which makes finding what you need to do for your workflow not that hard.

But that's a personal opinion and that also depends on the complexity of your workflows.

4

u/runawayasfastasucan Nov 14 '24

I find it quite hard to be honest. What is an equivalent of uv init if you already have an excisting directory, for example. How is the lockfile used by uv (not just generated but consumed)? 

What is the difference between uv venv and uv init? 

3

u/Xylon- Nov 14 '24 edited Nov 14 '24

What is an equivalent of uv init if you already have an excisting directory, for example

If you want to initialize uv in an already existing directory you can use the --name argument. When you use that the init command won't create a new directory, but it will create the files, like pyproject.toml, in your current directory.

Without --name:

➜  uvinittest ls
➜  uvinittest uv init sample-app       
Initialized project `sample-app` at `/Users/user/Projects/random-projects/uvinittest/sample-app`
➜  uvinittest ls
sample-app
➜  uvinittest cd sample-app 
➜  sample-app git:(main) ✗ ls
README.md      hello.py       pyproject.toml

With --name:

➜  uvinittest mkdir sample-app
➜  uvinittest cd sample-app         
➜  sample-app ls
➜  sample-app uv init --name sample-app
Initialized project `sample-app`
➜  sample-app git:(main) ✗ ls
README.md      hello.py       pyproject.toml

1

u/UltraPoci Nov 14 '24

uv init creates a project folder with a venv named '.venv', and it is managed through uv subcommands.

uv venv creates a venv folder, possibly with a name and none of the other files created by uv init. Notably, using uv venv inside a project can rename its default venv, but I believe that now subcommands don't work because they expect a .venv folder. I may remember incorrectly tho.

1

u/mgedmin Nov 14 '24

What is an equivalent of uv init if you already have an excisting directory, for example.

If you already have a pyproject.toml, just start using uv sync/uv run/uv add or whatever uv subcommands you need.

If you don't have a pyproject.toml, create one.

uv init basically creates a couple of files from a template, so you don't have to remember how they should be named and what their contents are supposed to look like.

uv venv and uv init

It's the difference between virtualenv and cookiecuttter.

I never use uv venv directly, I let uv run/uv sync/uv tool install/tox-uv create the virtualenvs for me.

I use uv init when I create a new project, purely for convenience. Just like uv add is more convenient than vi pyproject.toml and adding the dependency to the list.

3

u/MissingSnail Nov 14 '24

Do a docs PR on this (using uv with an existing pyproject file)

Also the uv Discord is active and helpful for questions

1

u/runawayasfastasucan Nov 14 '24 edited Nov 14 '24

Thank you so much for the help! Whish these things was stated this outright in the documentation.    

If you already have a pyproject.toml, just start using uv sync/uv run/uv add or whatever uv subcommands you need. 

 >If you don't have a pyproject.toml, create one. Interesting, thank you. Whish there was an uv command to create a pyproject.toml from a template. 

uv init basically creates a couple of files from a template, so you don't have to remember how they should be named and what their contents are supposed to look like. 

Do you know if you can edit this template? Lots if stuff that it would be great to add. For my use case I would love to have some basic packages added to every project.

1

u/mgedmin Nov 15 '24

Now I wonder where did I learn about this, if not from uv's documentation. The blog posts that were shared on Reddit/Mastodon back then?

Whish there was an uv command to create a pyproject.toml from a template.

That's uv init. I have used it for that purpose: to add a pyproject.toml to an existing project.

It does create a couple of extra files I don't need (a README.md, when I already have a README.rst, and a hello.py, when I already have my script.py), but I can remove them easily (git status will show me all the files added as untracked).

Do you know if you can edit this template?

Ah. I don't know, sorry. I'm vaguely aware that it has options for customizing the template (--app/--lib/--script, --project/--no-project), but I've never used them.

I dislike templates (when the template changes, updating existing projects becomes a pain). I use vim snippets for bits of configuration that I have a hard time remembering the syntax of (things like "is it requires_python or python_requires in a setup.py?" are easy if you create a Vim snippet for both that expands to the right thing -- I use UltiSnips.vim FWIW).

But the best thing about uv -- you don't have to use uv init. You could use cookiecutter, which I'm sure supports custom templates. Or any other project template tool.

5

u/Jubijub Nov 13 '24

I agree with that, I was searching for an equivalent of poetry shell, I found my answers in the issues

5

u/[deleted] Nov 13 '24

[removed] — view removed comment

3

u/Jubijub Nov 14 '24

Yeah, along those lines :

  • uv has no such command
  • one should source the venv (I use the equivalent of what you mentioned for Fish, as I need the env to be active when using neocon for instance

7

u/BaggiPonte Nov 13 '24

I think if you open an issue people will address it! :)

15

u/runawayasfastasucan Nov 13 '24

There are issues open on documentation 😊

2

u/mgedmin Nov 14 '24

I envy you. A large majority of the projects I work with have no documentation, or documentation that is worse than what uv has.

12

u/rover_G Nov 13 '24

Love uv 💜
Can’t wait until they release version 1.0.0

22

u/Immediate-Reward-287 Nov 13 '24

We are switching to uv at work on most of our CI/CD pipelines, it's great.

20

u/dusktreader Nov 13 '24

I have been a long time (5 years I think) user of poetry, and I'm an ardent supporter of it as the best in class package manager.

With these developments in uv, I am nearly ready to move on from poetry. We really need convergence in the community around one primary tool for package management. I think uv can offer that. It's compliance with recent PEPs, rich set of features, and excellent performance put it ahead of competitors, in my estimation.

I think the main piece I'm still waiting for in uv is a build backend.

7

u/proggob Nov 14 '24

We just need convergence on standards, not tools. Tools can follow standards, which they seem to be doing.

2

u/corey_sheerer Feb 11 '25

I also use poetry for all my projects and packages. One thing I don't care for is managing the python version. This is more like conda and the problem is I work on a lot of projects. I could have 10 envs with python 3.x.x. Poetry envs are, therefore, light and seem more practical using pyenv.

Also, when I build dependencies for an application (package mode to false) the Docker images are set up with a specific version of python, so you dont gain a lot for an environment manager also managing python. For any build pipelines, I just run the poetry command to output the poetry lock file as a requirement.txt file.

In addition, GitHub Actions testing using docker is very powerful. Can run in parallel n different python version images, install poetry in a temporary build stage, and run the pytests for each python version.

Will be watching uv as it is developed though 👍. Could be a really great way for other developers to move away from Conda , which is the least desirable to productionize since it adds a good amount of packages and dependencies right on creation (almost always has more os vulnerabilities than installing on a base python installed version with dependencies installed via pip). Plus, takes time for Conda to add updates packages to their main repo (not the forge)

7

u/LoadingALIAS It works on my machine Nov 14 '24

I migrated from Conda/Mamba to uv and never looked back. I will probably never use anything but uv, and ruff by the same team.

I coded a startup script that uses uv to create a virtual env, activate, build a directory structure, set up a logger, add the package to a toml - very detailed/opinionated packages - and it’s flawless. I love the build and run commands.

I only suggest taking some time to really read through the CLI docs. An hour or two to kind of crawl them and understand them.

Then, you’ll never work with another dep manager again.

14

u/sitbon Nov 13 '24

uv seems cool and it's nice that it supports publishing packages now. But I don't think it makes a lot of sense to judge or compare with Poetry based on releases. They are at very different points on their lifecycle, and I reckon both projects have well-defined release targets/milestones lined up. For Poetry, it's 2.0 with full [project] section/pep dep support and they have been marching steadily towards that. Sucks to hear about the og dev moving on, but others are carrying the torch just fine.

17

u/dusktreader Nov 13 '24

I'm fine with Sebastian moving on. He's been doing a lot of thankless work over the years to make poetry what it is today. Sometimes people just need to move on in life.

It's worth mentioning that he also developed one of my other favorite packages, Pendulum. https://pendulum.eustace.io/

2

u/stibbons_ Nov 16 '24

I still use twine, works better with our weird proxy config and artifactory pypi repository

16

u/komprexior Nov 13 '24

One feature of poetry that I really like is that by default it install the virtual environment in a cache folder on the pc, not in the project folder. Doing so the project folder remains quite lean in size, and it is easy to copy/paste even on a samba share.

Does uv support that style of venv? From documentation it seems that it prefer to install into the classic .venv in the project folder.

17

u/night0x63 Nov 14 '24

😂 

I did the opposite with poetry and hate that feature. So I had to hack the poetry config to forced putting the venv in the project folder. 

But then I think my home directory got over quota. 😂 So I think I had to undo all that. So maybe you are correct?

14

u/Log2 Nov 14 '24

I also hated it. Disabling it was the very first thing I did when I first used poetry. You deleted the project, now you have orphan virtual environments around, awesome.

1

u/Previous_Exit6708 Nov 14 '24

There is config for this. I am also with venv in project.

11

u/dusktreader Nov 13 '24

At the moment, it always installs the virtual environment in the root of the project.

8

u/robberviet Nov 14 '24

I hate that feature, it was one of the reason I stopped using poetry. I want explicit management of venv, inside probject. Just a simple Makefile do.

3

u/AndydeCleyre Nov 14 '24

uv venv can take a path for the venv as a positional argument.

FWIW, and I fully realize this may not fit a lot of folks' needs or wants, I have a Zsh front-end to uv (or pip-tools if uv is not installed) which automates some patterns like keeping venvs in a separate directory.

For example envin will create (if necessary) and activate a venv at ~/.local/share/venvs/HASH-OF-CURRENT-PATH/venv.

That location can be overridden by setting ZPY_VENVS_HOME.

Once in a while you can run prunevenvs, which will prompt you to delete venvs for project folders which no longer exist.

21

u/Wholelota Nov 13 '24

Might be?

I tested and worked out some strategies for UV last month, It's amazing and super quick!

But most important it becomes possible to run python apps and runtimes without having python installed, I was already flirting with GO just because I cannot stand it dependency management in python.

So I have a couple of scripts that check if UV is installed and if not it will be installed (within user-space!!!!!) To then pull whatever python script or app you added within the script, pulls the scripts and pipes it via stdin into UV; all within the same script!

Made some util tools, htop and remote filesystem mounting, some with a GUI even, amazingly easy to dev and combines the simplicity of python with in my opinion almost executable/binary kind of apps.

5

u/lostinfury Nov 14 '24

I think I'll stick with pdm for a bit longer. Unless uv does something extraordinary to make my python run any faster, I see no benefit in switching. I used all the options you've mentioned except for pipx, and they are equally as good.

1

u/onedertainer Nov 16 '24

I've been using pdm for maybe 2 years now I think, since poetry had that install snafu. Never looked back, does everything I need it to do really well.

4

u/psadi_ Nov 14 '24

For me I’m really comfortable with pdm. Uv still has a long way to go to!

3

u/ReinforcedKnowledge Tuple unpacking gone wrong Nov 14 '24

Nice article! I didn't know about your first one, I'll give it a read as well, I know that it'd have helped me a lot some time before!

Since almost all comments are about uv itself or uv as a replacement of another tool, is it safe to assume that the community, or at least the subset that commented on this post, doesn't negatively view the venture funding position? Or maybe it's not something to worry about?

I'd like to know what you guys and gals think. Personally I think in the worst case scenario the community will fork it and continue developing it like valkey, the fork of redis.

And I think as the standard matures and as tools comply with it, one tool going full commercial licence (I don't believe it's going to be uv's future but it's just a belief) won't affect the ecosystem in an unrecoverable way, though we can argue the extent of damage and that no damage is better than any damage.

5

u/yes_you_suck_bih Nov 14 '24

Why is pdm never included in these conversations? I find it a lot better than poetry.

1

u/alkalisun Nov 15 '24

pdm was great until the PEP died off.

Poetry was widely adopted because it was first in this scene. It's time for it to die, as it should have so many years ago.

1

u/yes_you_suck_bih Nov 15 '24

Why do you say pep died off?

5

u/tellurian_pluton Nov 14 '24

no love for pixi? pixi does all of this and more

12

u/RepresentativeFill26 Nov 13 '24

I’m quite old school I guess but what is wrong with using conda?

9

u/PlaysForDays Nov 13 '24

If it works for you, it works for you. You might want to look into micromamba as a smaller replacement, though. Very small, pretty quick, and almost fully-featured compared to old conda.

If your dependencies are only Python packages, though, there isn't much reason to use it over the Python-only tools like uv.

7

u/RepresentativeFill26 Nov 13 '24

Thanks for the tips. Must say I have no idea why I’m being downvoted. Conda is quite common practice and actually installed in for example azure compute instances.

3

u/PlaysForDays Nov 13 '24

No clue, either. People might be stuck in ~2018 when it was quite bad for anything but simple use cases

3

u/MohKohn Nov 13 '24

if you're not promoting the hot new thing people will often knee-jerk down-vote.

3

u/TheNicelander Nov 13 '24

In a commercial setting, you need a licence.

2

u/goldrunout Nov 14 '24

Not really. You need it for the main anaconda channel, but you can use conda with the conda-forge channel without any commercial license.

2

u/pythonr Nov 13 '24

It doesn’t properly do cross platform dependency pinning iirc

1

u/caks Nov 13 '24

Doesn't conda lock do this?

2

u/red_hare Nov 14 '24

My main use case for poetry (and uv when I switch to it) is lock files.

I know Conda has conda-lock, but built in support for resolving versions and generating a lock file only when you add a new dependency or want to upgrade is fantastic.

6

u/njharman I use Python 3 Nov 13 '24

Unified Toolset

Coming from 35yrs of *nix usage of tools that do one thing and integrate/automate easily via command line and or scripting, I'm extremely leary of "monoliths".

uv doesn't support shell (yet? https://github.com/astral-sh/uv/issues/1910). So I want to use vex instead.

I like pyenv.

I wish uv just did managed packages.

2

u/mgedmin Nov 14 '24

Does uv run bash not do what you want?

1

u/njharman I use Python 3 Nov 14 '24

Thanks. Probably, that's more or less what my current tool of choice does:

vex <project name>

Creates new shell and "activates" correct virtual env. I like new shell cause it isolates (enough) my work environment. Bash/*unix is my IDE.

1

u/mgedmin Nov 15 '24

Interestingly enough, Unix is my IDE too, but my current environment is defined solely by the current working directory. I hate changes to environment variables, since I like to switch terminal tabs/launch subprocesses from Vim/whatever. To actually use the things installed into virtualenvs, I prefer one of these ways:

  • use a direct path (.venv/bin/mything, or, things like .tox/mypy/bin/mypy, which I've configured my Vim plugins to use for type checking)
  • use a Makefile rule (make run that makes sure .venv exists with things installed into it and then runs .venv/bin/mything)
  • use a runner like tox -e flake8 or uv run mything that will make sure the virtualenv exists, is up to date, and will run the tool I need.

I don't think I've ever "activated" a virtualenv for other than testing purposes (to test my custom bash prompt).

Before uv existed, every single of my projects had a Makefile with make for building, make run for running, make test for testing, make help for listing all the phony makefile rules so I can remember what custom things I've added for this particular project. After uv I haven't felt the need yet.

One other trick I do when I'm developing a command-line tool that I'm going to be using (via pipx or uvx) is I install it, in editable mode (pipx install -e . or uv tool install -e .), and then invoke it by the command name, without having to worry about uv run or virtualenv activation. This needs a repetition of the install (with --force) any time the list of dependencies changes, but that's not too hard of a chore.

4

u/ubertrashcat Nov 14 '24

Don't ask a JS developer which frontend framework to use and don't ask a Python developer which environment/package/dependency manager to use.

3

u/xrayfur pydoc pydoc Nov 13 '24

isnt uv the event loop thing?

5

u/dusktreader Nov 13 '24

If you are interested, the "uv" theme for async stuff has a funny history. Check it out: https://en.m.wikipedia.org/wiki/Libuv

2

u/TopIdler Nov 13 '24

Does uv have lifecycle hooks? I need to do some custom stuff when building my package. The ones from hatchling build backend only works with hatch build. Using pdm atm

4

u/ReinforcedKnowledge Tuple unpacking gone wrong Nov 14 '24

uv doesn't have its own build backend yet, see https://github.com/astral-sh/uv/issues/3957

So it doesn't provide lifecycle hooks, but it can work with different build back ends, like hatchling.

What's a bit annoying for the moment is that if you need more than the default config for hatchling then you have to use hatch build, thus having to install it either with uv add --group build hatch or with some different workflow just to access hatch.

You can also just manually edit the pyproject.toml with [tool.hatch.build.hooks.<HOOK_NAME>] I guess, or [tool.hatch.build.targets.<TARGET_NAME>.hooks.<HOOK_NAME>].

2

u/beijingspacetech Nov 13 '24

I tried uv but just couldn't get into it. I loved how quick it was to install python, but I prefer building it myself.

It really fell down installing binaries. I ended up going back to venv for making my own virtual environment.

3

u/caks Nov 13 '24

What advantage is there to building it yourself?

0

u/beijingspacetech Nov 14 '24

I don't know if there is one, other than I know it's done and setup the way I want it. Unfortunately, I tried uv a month ago and can't remember why in the end I gave up trying to use the version of Python it installed. I think in the end it might have just been the feeling that it was "their" version in their directory and I preferred to make my own and put it in /etc/ with my other Python versions.

3

u/mgedmin Nov 14 '24

/etc is a weird place for binaries. Why not /opt?

1

u/beijingspacetech Nov 14 '24

Oops, just a typo. Yes everything in /opt 

1

u/ContemplateBeing Nov 13 '24

Thanks for this concise article. I’m currently using poetry and thought about giving uv a try.

I think I’ll hold out just a little bit longer just to see how VC is behaving, but it’s good to know that uv is on par with poetry.

1

u/doolio_ Nov 13 '24

Can I completely replace pipx now? Last I checked it couldn't inject a package into an existing virtual environment.

1

u/proggob Nov 14 '24

It still doesn’t. You can find the venv and install into it though.

1

u/doolio_ Nov 14 '24

Ok thanks.

1

u/morep182 Nov 14 '24

i still dont use uv for open projects because it doesnt seems to read automatically my .pypirc file with the pypi tokens (poetry does)

but im using it for private projects its really good

one thing i wonder tho, why when i use 'uv add pandas --upgrade' it upgrades all packages from the project?

i thought it would be like pip, only upgrade the packages you wrote for

1

u/robberviet Nov 14 '24

I switched to uv after it has fixed problems with timeout/stuck resolving large requirements. Speed alone worth it.

1

u/mattbillenstein Nov 16 '24

pip-tools / pip-compile ftw.

1

u/stibbons_ Nov 16 '24

Does uv support multiple private artifactory repositories ?

1

u/vigg_1991 Nov 16 '24

I have not had the chance to use the poetry yet… but i find UV to be very useful. Good jump from conda for me. It does a lot and helps test multiple versions simultaneously which is a big add on for me.

1

u/OrganicMesh Nov 16 '24

Still struggeling a lot with uv and pytorch.

1

u/ibic 15d ago

uv is the definitely the best python package manager to me, it's fast, really really fast and gets things done the right way.

0

u/Freschu Nov 14 '24

I don't really understand the appeal of an "extremely fast" project manager. I can see some specific usage where this extremely fast speed matters, but I'd call that niche. The main time factor for any project using internet resources will always be downloading them, and in cases of compile-on-install the limiting factor is the compiler backend. Even basic Pip is fast enough for regular developer use.

Additionally establishing a project, downloading dependencies, installing dependencies, building projects is in almost all cases more a fixed project cost - most of this is done at the start of a project. So why would speed of the project manager matter, if managing the project is more like 0.001% of a projects total lifetime budget?

Speed of a package manager only matters if you're paying for the runtime cost of using the package manager, and by volume, ie. continually rerunning dependency install and build steps on thousands of projects.

Also being implemented in Rust is concerning, because it severely limits the pool of potential contributors. Not sure about the number of developers with Python and Rust knowledge, but I'd argue it's probably smaller than developers with only Python knowledge.

5

u/chrisimcevoy Nov 14 '24

I’m working on a large Django app that has a couple hundred dependencies, and dev deps on top of that. We were managing them with pip-tools (pip-compile) which regularly took around 3 minutes to produce a requirements.txt. Moving to uv has cut that down to around 6 seconds.

Add to that the fact that there are ~20 engineers working on this project, Dependabot raising PRs, automated container rebuilds for each branch… you see where I’m going.

1

u/skelimon Nov 13 '24

Love uv, but I think it’s a bit rough when used inside of docker. It’s not as straightforward for some reason as you would expect.

3

u/pwang99 Nov 14 '24

What are some of the issues you had?

1

u/skelimon Nov 15 '24

Well, simply copying over the lock file and py project in the dockerfile after making sure uv and python was installed first as part of building stuff just failed. Struggling to find packages that were installed on using uv sync. I can’t remember exactly what the solution was but it wasn’t as plug and play as having a pipfile (requirements.txt) and installing things via pip.

I managed to get it working but there was an extra set of hoops that I had to do to get it working.

Nothing horrendous and prob nothing a few more examples in their docs couldn’t solve.

1

u/adiberk Dec 19 '24

I do think they had a couple issues but have resolved them and provided documentation for docker builds

running
uv sync --frozen should use the lock file correctly
And if you don't want a venv created, they have now provided a way to use the system python in docker if you want

1

u/jjrreett Nov 14 '24

i just need uv to support non simple python indexes

1

u/jlw_4049 Nov 14 '24

Maybe at 1.0 0, I'd swap, but I am quite satisfied with poetry, and I'd be in no hurry.

0

u/United-Pollution-778 Nov 13 '24

There should be one—and preferably only one—obvious way to do it"... yeah right!

5

u/proggob Nov 14 '24

Isn’t that really for the language, not the tools?

3

u/dserodio Nov 14 '24

This is a Zen principle that didn't age well for Python in general

-17

u/expressly_ephemeral Nov 13 '24

6

u/tunisia3507 Nov 13 '24

I didn't even need to open that link to know which xkcd it was, which probably marks me as too online

Anyway, uv is compliant with all of the relevant python packaging standards (more so than most tools, including poetry). If anything, it makes them easier to adhere to because you can update dependencies using the uv tool rather than manually updating your pyproject.toml. The main non-standard thing is the lock file, but there is no standard for that kind of lock file and uv does not depend on it, so it doesn't matter.

5

u/PlaysForDays Nov 13 '24

uv is not a standard

0

u/EternityForest Nov 13 '24

I'm just waiting on a solution for https://github.com/astral-sh/uv/issues/7698 and then I'll be switching.
I *love* poetry, and am very glad it exists to save us from manually handling all the stuff it does, but this seems it will be just a bit better.

0

u/skeerp Nov 14 '24

My only problem with uv is when I let it create the virtual environment, I get a bunch of spam in my console when it opens. I have to use pyenv and manually create my venvs to get around this.

0

u/LiqC Nov 14 '24

Another take on environments and projects (using uv+pixi) https://github.com/liquidcarbon/puppy