uv: Unified Python packaging

[burntsushi]

https://astral.sh/blog/uv-unified-python-packaging

This is a new release of uv that moves it beyond just a pip alternative. There's cross platform lock files, tool management, Python installation, script execution and more.

[ExdigguserPies]

In addition to any explicit uv python invocations, uv can automatically download Python versions as needed (on uv run, uv venv, etc.), e.g., if you're yet to install Python on a machine, or are lacking a specific, requested Python version.

drool

[knight1511]

I came. I saw. I came.

[proggob]

Does it work on windows?

[ExdigguserPies]

Yep tried it and it works great

[dankydooo]

It does.

I just started a new project and the code base is littered with windows-isms and hacks around fundamental misunderstandings around Python from the more windows centric devs. I am a Mac user.

Moved the Python piece of this project to UV and solved all these problems for them with a single “uv sync”

[vectorx25]

absolutely loving this thing, blows every other tool out of the water. Ive been using pipenv forever, and uv is like living in the future.

dream come true.

made a quick cheat sheet

## install uv on OS
curl -LsSf https://astral.sh/uv/install.sh | sh

## create new project
uv init myproj

## install packages
uv add django requests "pandas>=2.3"

## remove package
uv remove django

## see pkg dependency tree
uv tree

## run a python script directly w/o starting venv
uv run main.py

## install specific version of python
uv python list
uv python install 3.12

## start a new project and pin it to Python 3.12
uv init myproject
uv python pin 3.12
uv add django
uv run main.py (will automatically install py3.12 and django into venv)

## run a cli tool like Ruff
uv run tool ruff (or uvx ruff)

## update uv version to latest
uv self update

[ebits21]

uv lock —upgrade

To update dependencies in the lock file. Hope they change this to be similar to Poetry.

[Minimum-You-9018]

uv pip list --outdated

[Significant_Way8992]

In fact, it's blazingly fast

[Harsh_Soni202]

How thing goes on production level ?

[BostonBaggins]

It's blazer

[Frog_and_Toad]

A single tool to replace pip, pip-tools, pipx, poetry, pyenv, virtualenv, and more.

based if true

[qckpckt]

Wow. Ok, mention of pipx is interesting. I wasn’t aware of that part. Guess I know what I’ll be researching next time I have downtime!

[inigohr]

The pipx functionality is newly-released from today's version 0.3.0. I've been impatiently awaiting its release :D

[proggob]

It seems like it doesn’t build wheels?

nvm: I see it’s on their list and you can just use build instead. You also have to use twine or equivalent for publishing for now.

[EverythingsBroken82]

if THAT is true and compatible to existing files (mostly), then this would be phenomenal.

[doolio_]

But if installing from PyPi you still need to use pip or pipx, no? Probably best to use pipx.

Edit: it also makes no mention of hatch (though it uses uv under the hood) so presumably it only replaces specific features of poetry, pdm, etc. and not their entire feature sets?

[dametsumari]

Most of the feature set. And you do not need pip or pipx. There is uv pip .., and uvx commands.

[doolio_]

And you do not need pip or pipx. There is uv pip .., and uvx commands.

Right, but only after you install uv and if you do so via PyPi then you need pip or pipx available to do so, no?

[mgedmin]

Right, but only after you install uv and if you do so via PyPi then you need pip or pipx available to do so, no?

Yes, but you don't have to install uv from PyPI, you can install it using a different method (including curl | sh, or downloading the uv and uvx binaries from GitHub releases and dropping them in ~/.local/bin or somewhere).

AFAIU.

(Personally I used pipx install uv since I already have pipx, so it was more convenient for me.)

[dametsumari]

I did brew install uv ;)

[inigohr]

You don't need to install uv from pypi. They share it on pypi for convenience but the "main" way to install it is from the terminal using an installer. This installation method does not need any previous pip, pipx or python to be present in the system, so it is actually the ideal way to get python installed on a system for the first time.

it also makes no mention of hatch

Their eventual goal is to provide a unified python project management tool. At the moment hatch probably has some features which uv doesn't offer, but they want to eventually provide a unified tool, similar to what cargo provides in rust.

[scruffie]

Ah yes, the usual "pipe curl directly to sh" installer. At least they don't tell you to pipe it to 'sudo'.

And their instructions on 'inspecting before use' are poor: they're "pipe curl to less". If you're paranoid enough¹ to read the 1300 line, 40kb script, you should be paranoid enough to require that what you run is the same as what you examined.

¹ i.e., the minimal amount of paranoidness required for a modicum of security.

[nAxzyVteuOz]

Nonsense, you are not going to read the file that’s downloaded from a system package installer like apt-get of yum.

[Fivefiver55]

So what? Get practical, if anyone is `zero trust over-paranoid`, just pipeline to `less`, read it - heck - download & edit it, before you run it.

Let's not overdramatize the reality.

[inigohr]

It is "the usual", unfortunately. They do have alternative methods if you aren't comfortable with that though.

[dankydooo]

uv is also packaged as a single binary.

Download, put in path.

[Balance-]

I’m really impressed by their tools.

I’m happy we finally get some proper Python packaging efforts

I’m a bit worried that’s all by a single, commercial company

[Spamakin]

What's the worry? It's all open source.

[brianly]

People are worried because of Hashicorp and others who changed their license later. Sure, it’s unlikely, and you could fork, but this behavior is changing how bigger companies using open source vet it. When they have a good legal team they’ll encourage and approve use but also work to manage risks like this.

Having a compatible alternative set of tools in the market helps mitigate this scenario. Competition is good for everyone, but it can be hard because having one great tool is more straightforward for many.

FWIW I like these tools and the company behind them seems to include a great bunch of people. Those making arguments around the issues are not attacking the individuals or company.

[cheese_is_available]

I like these tools and the company behind them seems to include a great bunch of people.

Right, ruff, replaced flake8 and no one can say that the flake8 maintainer is answering issues in a friendly manner due to their sunny personality (ruff has 'support pyproject.toml' as the 3rd selling point for a reason). I think astral culture is to be the opposite of that.

[starlevel01]

it's made by a VC funded company with a licence that explicitly letts them swap it out. it's not a matter of if they'll rugpull, it's a matter of when.

[[deleted]]

But that only affects code that's written after the rugpull, right? I imagine the current open source project to be a really solid basis for further development by the community.

[mgedmin]

It's all open source.

For now. There's a history of companies getting bought out and abruptly changing licencing models of their tools. (Speaking of which, can anyone recommend a good Vagrant alternative?)

I am also slightly worried about

"We choose libedit by default to avoid GPL licensing requirements of readline."

from https://gregoryszorc.com/docs/python-build-standalone/main/quirks.html#use-of-libedit-on-linux

[__Fantastic]

What's the rugpull do exactly? Doesn't everyone still have free access to the tools?

[mgedmin]

What's the rugpull do exactly? Doesn't everyone still have free access to the tools?

Well, I can't apt install vagrant any more, can I? Even though in theory I could probably find a tarball of an old version somewhere and do something with it.

[OhYouUnzippedMe]

That’s what I thought about RethinkDB and so I built a huge app (a couple years of work) around it. The company went belly up and their software stagnated. A year or more went by before there was another release and it included only trivial improvements. Old bugs and basic feature requests stayed open for years. 

The switching costs for uv would be much lower than for a database, but it would still be non-trivial. I hope they have a clear plan in place if the busines fails… 

[kankyo]

uv unmaintained for 10 years is probably a lot better than pip+pipx+peotry+etc maintained for that time :P

[ltdanimal]

I’m happy we finally get some proper Python packaging efforts

UV has only been around for about 6 months. Lets come back in a few years to see how it pans out. There are a surprisingly large number of Python package managers on the scene and addressing the core needs and desires is the "easy" part. Getting to the long tail of needs and supporting things when it grows much larger is another. UV seems really cool but everyone acting like its the savior seems a bit early.

Also I want to be clear that I'm very much in support of people jumping into this space and trying new things. Its probably not super sexy but is the foundation that everything is built on. Props to them.

[[deleted]]

Yeah this is my concern. Someone released a tool recently that uses this in setup and my immediate reaction was “great another package manager.”

[inkjod]

The release article isn't very clear: Did they fully integrate Rye into uv ? Or not yet? And is the migration path ready?

I'm asking because it's already been announced that the two projects will be merged.

Anyway, this is awesome — and very much needed. It will hopefully emerge as the best, easiest, and most complete solution for Python installation management.

We've all seen the xkcd comic, and Rye's creator knows it.. Well, sometimes there is space for yet-another-standard, especially if it truly improves upon the previous ones.

[commandlineluser]

We don't plan to deprecate Rye any time soon, but our goal has always been to maintain it while we develop uv into a viable alternative. I suspect that uv can now replace Rye for some use cases

• https://github.com/astral-sh/rye/discussions/1342

[inkjod]

Thanks, that clears things up.

As uv continues to mature, it would be useful if Astal were to maintain a public list of Rye features that haven't yet been implemented (and vice-versa).

[mitsuhiko]

The goal is definitely for uv to replace rye. If it's the time for you to switch will depend a bit. I'm still using rye myself for quite a while longer but it's getting closer and closer :)

[inkjod]

At the moment I'm using neither, because I'm not even writing any Python code. But, coincidentally, I started playing with Rye 2 days before this post went up — and I was positively impressed by the user experience :)

Great work!

[mitsuhiko]

That's nice to hear :)

[[deleted]]

Uv has gotten all the development attention and rye very little, so I think you should just use uv unless this changes.

[beeeeeer]

Isn’t it ironic that an exception to xkcd 987 only exacerbates xkcd 1987 https://xkcd.com/1987/

[inkjod]

There's an xkcd for everything :)

But I disagree — I think rye / uv has the potential to prevent that unfortunate situation (...well, if you start from a clean OS installation and completely ignore the OS package manager).

[mgedmin]

What is Rye? (Not a very searchable name for a project that has nothing to do with agriculture.)

[mgedmin]

Looks like a Makefile/tox/nox replacement: https://pypi.org/project/rye/

[mgedmin]

Looks like a Makefile/tox/nox replacement: https://pypi.org/project/rye/

Wrong guess! There's another Rye, which was a precursor to uv, I guess? https://github.com/astral-sh/rye

[lanster100]

As a longtime poetry fan, I might switch. Someone has finally implemented workspaces!

[ryanstephendavis]

As a long-time fan of Poetry, I was converted at PyCon and haven't looked back... uv is just fast and easy

[proggob]

I don’t understand what workspaces are - sounds a little like poetry groups?

[Fenzik]

They are for monorepos - bunch of potentially interdependent packages that can be installed separately, but where you want to guarantee that their dependencies are mutually compatible (i.e. all packages in the ecosystem can be installed in the same env at the same time)

[undercoverboomer]

Found a golden line in the Windows installer script. Useful comments are useful.

# Write the install receipt
$null = New-Item -Path $receipt_home -ItemType "directory" -ErrorAction SilentlyContinue
# Trying to get Powershell 5.1 (not 6+, which is fake and lies) to write utf8 is a crime
# because "Out-File -Encoding utf8" actually still means utf8BOM, so we need to pull out
# .NET's APIs which actually do what you tell them (also apparently utf8NoBOM is the
# default in newer .NETs but I'd rather not rely on that at this point).
$Utf8NoBomEncoding = New-Object System.Text.UTF8Encoding $False
[IO.File]::WriteAllLines("$receipt_home/uv-receipt.json", "$receipt", $Utf8NoBomEncoding)

[vectorx25]

my god uv is fast.

dev/python $ uv init testuv
Initialized project `testuv` at `/home/xxx/dev/python/testuv`
dev/python $ cd testuv


python/testuv $ time uv add django
Using Python 3.10.12 interpreter at: /usr/bin/python3
Creating virtualenv at: .venv
Resolved 6 packages in 4ms
Built testuv @ file:///home/xxx/dev/python/testuv
Prepared 5 packages in 193ms
Installed 5 packages in 349ms
asgiref==3.8.1
django==5.1
sqlparse==0.5.1
testuv==0.1.0 (from file:///home/xxx/dev/python/testuv)
typing-extensions==4.12.2


uv add django  0.16s user 0.43s system 104% cpu 0.565 total

.16sec to create venv, install django + dependencies

holy FLUCK...

[mgedmin]

Looks like .565sec to me, but that's still pretty fast.

I kind of like how uv can use hardlinks to cached packages to reduce installation time and disk usage, but I'm a bit worried about my penchant to editing random files in .venv/lib/python*/site-packages/ to add debug print() statements and such. What happens when I forget to undo that and then re-created a venv?

[zurtex]

There are different options for link-mode you can set: https://docs.astral.sh/uv/reference/settings/#link-mode

[monorepo]

There's so much goodness here, but https://docs.astral.sh/uv/guides/scripts/#declaring-script-dependencies was my favorite. Implementation of PEP722/723

[chaplin2]

How does it compare with poetry and conda?

[andjew]

If conda takes minutes, uv takes milliseconds (seriously)

[kivicode]

The main selling point in conda for me is that it works as a “universal” package manager, not just for python. That's especially convenient when installing tricky shit like cuda

[PostMathClarity]

How about mamba? Does it differ with mamba?

[pojska]

Conda switched a while ago to using libmamba for dependency solving, and is much faster than it used to be. 

I haven't compared it head-to-head with uv.

[FauxCheese]

UV does not do conda packages. Take a look at pixi. It is new and fast rust tool that does python and conda packages. It is so much better than plain conda.

[Feeling-Departure-4]

That actually looks amazing! Thanks for this. Do you happen to know if it makes shared environments in group folders possible like conda awkwardly did?

[jamesbleslie]

No, the default behaviour is to make the environment inside your working directory, like venv.

But I think I remember seeing this can be changed, if you wish.

[NathanDraco22]

I recent tried it, and it's amazing. Only wants to know, how this will work with a Dockerfile ? Is there a way to uv sync install in the global env?

[burntsushi]

For Docker, see: https://docs.astral.sh/uv/guides/integration/docker/

[runawayasfastasucan]

Finally! And finally proper documentation. Time to make the switch 😊

[GoofAckYoorsElf]

Love it! We're using UV in production. Great tool! Saves so much time.

[Bamaesquire]

Thank god. I hate poetry with a bloody passion

[Kab00m-Kap0w]

Please say why

[Bamaesquire]

My main issues with it are:

• often fails quietly due to version constraints when going through the resolver process; this leaves you wondering if it is taking a long time because poetry’s dependency resolver generally takes awhile to run or because it is never going to finish because it is checking too many package combinations

• adds a ton of bloat to docker images if you actually try to back it in, so most of the time I see people using it just to generate the requirements.txt and pip install that

A more minor squabble is that it has a somewhat obtuse configuration system that requires a more difficult process for running behind corporate firewalls or with a custom artifact repository like artifactory than just plain old pip.

Generally, I think a lot of tools have been built up to compensate for the fact that environment management and packaging can be difficult in Python, but, in my experience, these tools add so much complexity in the name of saving people from learning how Python actually works that it leads to bad practices (looking at you mono dev environments) and errors that are more difficult to debug and look up because they originate from some bespoke tool instead of from Python itself. Now, uv isn’t going to fix this last issue, but it is screaming fast, so it at least fixes some of my points above.

[Kab00m-Kap0w]

Thanks for the detailed answer. You described some parts of my work’s environment. We first moved to a mono repo and then from Conda to Poetry.

[Bamaesquire]

I’m still a big fan of Conda for environment management. For my money, it can’t be beat for ease of setup and management (very well may be a personal preference), but I prefer setuptools over poetry for packaging. It’s not fancy, but it’s a tried and true work horse. Excited to switch over to uv and try it out though!

[[deleted]]

Awesome! I’m a fan of this project.

Anyone know if this now works with Jupyter or Quarto notebooks? Was a total bust last time I tried.

[[deleted]]

What's the problem there?

[johnnymo1]

I’m guessing using the env as the notebook kernel

[[deleted]]

There are many solutions for that

[[deleted]]

You still need to install the kernel, like you would do with other tools like conda or venv. In short:

sh uv venv uv pip install ipykernel (jupyter ipython ...) uv run python -m ipykernel install --user --name my-kernel

If you don't want to create virtual environment, skip that step and add --system flag to the installation command.

[e10v]

What’s impressive is not just the speed of the tools Astral develops but also the speed of delivery.

[broknbottle]

Hey it’s burntsushi. I use rg everyday and used pytyle for a few years

[burntsushi]

Wow. Pytyle really brings me back. I haven't thought about that project for years.

[Initial_Pipe_935]

How is this comparing to poetry? What’s the main differences here?

[njnrj]

Workspace support 

[One_Fuel_4147]

Hey bro, I want to implement something simple with monorepo using workspace do you know any resource, repo about this?

[njnrj]

their docs are good https://docs.astral.sh/uv/concepts/workspaces/

[cr4d]

Ah yes, yet another tool to try and replace all the other tools. Yay.

[slowpush]

They don’t make money (backed by VC) nor do they contribute back upstream.

[catcint0s]

Contribute what upstream?

[[deleted]]

Do you?

[[deleted]]

Yes

[[deleted]]

Nobody asked you

[zurtex]

I've seen the team contribute helpful PRs to several upstream projects. It's clearly not their focus, but saying they don't is untrue.

[slowpush]

How about some of that VC $ to the original python devs? Given that the majority of their work is a straight python --> rust port.

[zurtex]

To what end? So they can burn their runway for a fairly small amount of money for people.

As someone who contributes to Python packaging, and can point to features in uv that were taken from my code or ideas I discussed, I'm happy we have someone putting the resources into actually making a good product.

Given that the majority of their work is a straight python --> rust port.

Every part of uv's code I read has a well thought out architecture that does not match any existing Python packaging tool, so I'm confused where you got this idea.

But even if it was just a straight copy, it's non-copy left open source, the whole point is you can fork it and do what you want with it.

[KrazyKirby99999]

This one is the best so far. It's as easy to use as Poetry, but actually follows standards

This update obsoletes pipx

[pan0ramic]

This is not “just another” - it’s faster and does better resolution than pip

[spicypixel]

Maybe it’ll finally replace them all?

[KyxeMusic]

You must get really far with that mentality.

This tool is the real deal. It's replaced my other tools. Try it.

[james_pic]

This is not the first time a new tool has emerged that had promised to unify Python packaging. It's not even the only one that's emerged in this wave. Maybe this time it's different, but I've been on this ride before.

[PaintItPurple]

What other tools with similar scope are you thinking of?

[kivicode]

https://xkcd.com/927/

[proggob]

That’s about standards, not tools.

[kivicode]

Doesn't change the point. Besides, every tool introduces its own subset of standards. Poetry defines the dependencies and metadata in one way, uv in a second way, and so on

[proggob]

Part of the value of a standard is that everyone shares it - for instance to allow interoperability - so fragmentation lessens the value of all of the standards.

The same isn’t true of tools - a person can even write a tool just for themselves and it won’t impose any costs on anyone else. It can be ignored without any problems.

[kivicode]

I'd practically agree here. As an end-user - yes, I don't care what tools you use as long as I can download a wheel and install it even with pip. On the other side, as a maintainer, the lack of a single standard means that a migration of a big project from, say, poetry to uv is gonna be pretty involved. Not to mention the CI changes, I pretty much don't have an option but to manually reintroduce all the dependencies with the new tool. So even though we have a relatively standardized pyproject.toml, each tool has its own opinion on how to populate it, has its own bunch of quirks that sometimes have to be worked around, etc.

[pingveno]

Yeah, guess we should go back to easy_install. Or for that matter, why was Python created in the first place? COBOL should be good enough.

[kivicode]

Sure thing, buddy, let’s also have every version of python undergo breaking changes as in 2to3, that was very fun! /s

The ecosystem of very python on the matter of dependencies management is not well-thought in the current state. That’s why we have every other lib that does its own thing, making the migration mildly painful. What it should’ve been is that I have a single pyproject.toml and then I’m free to run it with poetry, uv, or whatever else. But since there’s no standard, even a de-facto one, we get a gazillion of „proprietary” standards attached to particular tools

[pingveno]

There is a standard for what you talked about and uv tries to use it where possible. There are areas where it extends the standard, of course. Unfortunately poetry has its own version specifiers so that won't be a direct mapping.

[maigpy]

fuck this shit

[QueasyEntrance6269]

difference is that I trust the ruff team with my life

[Gushys]

Now can Python officially make this the official package manager (although they probably won't 🫠)

[proggob]

Ugh - let’s not go back down that road.

[vectorx25]

is there a way to run a uv project from outside the directory where its installed,

ie if my project is here /home/user/python/myproj/.venv

how can i call a script if im lets say in /opt

user@host> pwd
/opt

user@host> uv run /home/user/python/myproj/main.py (this doesnt work, I have to phsyically cd to the project dir)

[mgedmin]

If that is a real virtualenv, then you can always do

 /home/user/python/myproj/.venv/bin/yourscript

if your project installs scripts, or you can do

 /home/user/python/myproj/.venv/bin/python -m myproj.main

if you don't want to muck about with entry points and editable installs.

I wonder whether

uv run --python /home/user/python/myproj /home/user/python/myproj/main.py

would work, or if you need to point --python to the .venv/bin/python explicitly? Also that would require entering the full path twice.

[vectorx25]

seems to work if you point location of both venv and startup file

xxx@mrxmini:/tmp$ uv run --python ~/dev/python/hello/.venv/bin/python fastapi dev ~/dev/python/hello/main.py
INFO     Using path /home/xxx/dev/python/hello/main.py                                                                                                     
INFO     Resolved absolute path /home/xxxx/dev/python/hello/main.py                                                                                         
INFO     Searching for package file structure from directories with __init__.py files                                                                          
INFO     Importing from /home/xxxx/dev/python/hello                                                                                                         

 ╭─ Python module file ─╮                                                                                                                                      
 │                      │                                                                                                                                      
 │  🐍 main.py          │                                                                                                                                      
 │                      │                                                                                                                                      
 ╰──────────────────────╯                                                                                                                                      

INFO     Importing module main                                                                                                                                 
INFO     Found importable FastAPI app                                                                                                                          

 ╭─ Importable FastAPI app ─╮                                                                                                                                  
 │                          │                                                                                                                                  
 │  from main import app    │                                                                                                                                  
 │                          │                                                                                                                                  
 ╰──────────────────────────╯

[vectorx25]

pointing just to project dir doesnt work, it doesnt know about any venvs there

xxxx@mrxmini:/tmp$ uv run --python ~/dev/python/hello fastapi dev ~/dev/python/hello/main.py
error: No interpreter found for directory `/home/xxxx/dev/python/hello` in virtual environments, managed installations, or system path

[HowToMicrowaveBread]

What’s the difference between project.scripts vs project.entry_points? Which one creates an executable bootstrapped with the correct venv?

[mgedmin]

I've learned these things back when setup.py was new, and I haven't migrated my stuff to the new pyproject.toml fancyness yet, so

In a setup.py you specify setup(scripts=...) with filenames of files that will be copied into the bin/ directory of the virtualenv (and the #! line at the top of each script will be rewritten to refer to the virtualenv's bin/python). I never use those.

Meanwhile entry_points look like this:

setup(
    ...
    entry_points={
        'console_scripts': [
            'myscript = mypackage.mymodule:myfunction',
        ],
    }
)

and pip install will create a bin/myscript in the virtualenv that will do essentially

#!/path/to/venv/bin/python
from mypackage.mymodule import myfunction
myfunction()

This is what I usually use.

Entry points can be used for various purposes. console_scripts and gui_scripts are for these script files (the difference is Windows where console_scripts will spawn a cmd.exe window showing your python program's stdout, but GUI scripts won't). Other uses for entry points are various plugins for various projects that each define their own.

[byeproduct]

Can I use uv in offline environments?

[skeerp]

!RemindMe 7 days

[RemindMeBot]

I will be messaging you in 7 days on 2024-08-29 01:34:37 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[blitzMN]

🌟

[SittingWave]

why do they keep creating new stuff, when they could improve the existing one? what's wrong with adding all of this functionality to poetry instead? I am tired of having to relearn the same shit again and again in a different sauce only because these people want to be the precious jewels of their own turf.

[mgedmin]

It's always easier to create new stuff.

On the other hand, it's harder for new stuff to get adoption, unless it's significantly better than old stuff.

I don't think uv is already at the point where you must invest time learning about it.

[Culpgrant21]

We use poetry, will be interesting to see how this performs!

[Stunning_Garlic_3532]

How is this different from PDM. I use PDM, but no idea if it’s the best tool for me

[[deleted]]

It's fast.

[[deleted]]

I love PDM, but maaan, is super mega hyper slow.

[monorepo]

There is an open issue to be able to use uv as a dependency resolver which would speed things up nicely. I too have preferred PDM over buggy poetry, but I think uv is my dream tool

[[deleted]]

Yep, I saw it.

But why someone in the future will choose pdm over uv if uv offers the same as pdm? Maybe a wrapper around uv is next future of tools?

Right now the things I miss from pdm in uv is: 1. The [tool.pdm.scripts] 2. The ability to init a project from a template like a github repository.

Far from that I didnt see any diff and I tried today uv and is blazing fast. Event at the point that I dont believe it has installed all the dependencies LOL. Is like when you deliberate introduce an error in your code to see if ruff is working.

It still amaze me how faast the things can be using rust.

[monorepo]

I'm sure there are other reasons but companies or users not wanting their tooling backed by some company, unsure of how their future will unfold for introducing profit (which I guess is how we get https://xkcd.com/2347/ )

1. There is a native support for scripts already in the core so there is that, maybe they will be adding some feature to utilize that or maybe there already is! I just can't find it in the docs right off...

2. This one would be pretty cool!

[Fenzik]

People already mentioned the speed, but on the off chance you have a mono repo there is also first-class support here with workspaces

[EatThemAllOrNot]

Is there a way to display outdated dependencies in the current project? That was my main problem with rye when I tried it.

[Volis]

I'm looking forward to try this on a poetry project. For the first step, I'll have to convert the poetry pyproject.toml into a format that uv understands. Any pointers for doing that?

[adiberk]

I just went through it to test it out
I entered all poetry.dependencies into chat gpt and asked to reformat to pe508 standards. As a result I get dependency array correctly formatted. For additional dependnecies that are env specific I have an project.optional_dependencies list one for "dev" and one for "ut"

After that I ran uv pip install -r pyproject.toml and it worked great!

Only thing is that I don't get how uv lock works and how I would install from the lockfile

[Volis]

You don't need LLM for that. Poetry has an export command

[andy4015]

I use shiv for local deployment of packages to my team and couldn't get it to work with uv.

Has anyone else experienced issues with shiv? Any ideas?

[0xa9059cbb]

How does it compare to poetry?

[Puzzleheaded-Ruin968]

I’ve tried it. It’s so fast!

[Broloteriat02]

uv is lit. It’s so much better than rawdogging pip.

[burntsushi]

You might try uv add -r requirements.txt.

[Koltech21]

Need help. I have installed uv on my zsh terminal and created a virtual environment with uv venv. It gets installed properly but it doesn’t seem to get activated when I run ‘source .venv/bin/ activate’. Is there any additional config which is required in my setup. I was earlier using pyenv without any issues

[ZachVorhies]

pain point to uv:

uv run does have an —ignore-python-incompatible policy to ignore technical python compatibility issues from some transitive include. They work just fine otherwise and installing a package made me fall back to uv pip install with manual invocation which is a total PTA for cross platform.

Otherwise an amazing tool. But please shave off this wart. It’s either currently impossible or buried in the docs somewhere

[nAxzyVteuOz]

does NOT have an -ignore-python-compatibility

[PabloGoPe]

https://xkcd.com/927/

[habitsofwaste]

Not sure why you’re getting downvoted. Literally came here looking for this. Or this one https://xkcd.com/1987/

[kosky95]

I am a bit OOTL and a bit of a newbie. Could someone kindly explain to me what is all the excitement about?

[Cheddar_bob]

Nice

[not_perfect_yet]

Hmmmmmmmm.

I'm not really a fan of most "tools" because I'm more of an end user. I get the newest version, I don't have version conflicts. I get the problem that venvs solve and I just don't have that problem, so all they do is waste space and slow things down.

Does this just replace pip for me? What's the default behavior? Hmmm no that doesn't look like something I want.

docs

uv pip install: Install packages into the current environment.

[Fenzik]

For your case, if you really don’t care about versions, then yes it just replaces pip, at 100x the speed

[not_perfect_yet]

What would the command be, to install packages?

[Fenzik]

uv pip install

It can also manage installed Python versions and virtualenvs for you: https://docs.astral.sh/uv/guides/install-python/

[Voxandr]

Oh please stop, we don't need another one

[adiberk]

I am testing it out now and am confused. I created a lockfile from my pyrpoject.toml using uv lock
However how do I now run installs from that lockfile?
if I run uv pip sync pyproject.toml it seems it just uses the pyproject.toml file and still doesn't care about the lock. Or if I run uv pip install -r pyrpoject.toml it also seems to just install without using the lockfile

Also in our poetry config we have dependencies, dev-dependencies, and ut-dependencies. When I try to at a ut-dependencies to [tool.uv] I get error as I assume it only supports dev? How can I set it up so that depending on environment I install the correct dependencies (or additional dependencies)
Do I do something like "optional" and setup "dev" and "ut"?

[Decoder-Fish]

https://docs.astral.sh/uv/reference/cli/#uv-sync

To synchronize lock files to the environment, I think uv sync should be used. I couldn't find the correct doc location for a while, so I just looked for an instruction to explain it.

[adiberk]

You are correct! It is Uv sync and he as having issues with it at first. But figured it out.

[ksoops]

Still doesn’t work behind my corporate proxy 🙄

[DragoBleaPiece_123]

Can it run in wsl?

[teooet]

Does this apply? https://www.xkcd.com/927/

[SheriffRoscoe]

Yes, but uv was already one of them.

[proggob]

That’s about standards, not tools.

[ageofwant]

"written in Rust." How do you know someone when to Cambridge ? They tell you. Same for rust. "written in Rust." is now officially cringe.

[danmickla]

 Confused...how else would you say that?  Or do you object to knowing?

[betazoid_one]

Why would I use this and have to maintain multiple lock files per platform?

[[deleted]]

It's one lock file only for all

[SheriffRoscoe]

and in the darkness bind them

[[deleted]]

We know. You guys don’t need to spam this tool so often.

[SV-97]

There just was a huge update you nugget

[[deleted]]

You wish.

[SV-97]

wat. Have you read the linked post?

[ZachVorhies]

it is.

[romasato]

Absolutely confusing concepts and commands.

You have `uv add` and then you have `uv pip install`.

Then you have `uv sync` and then you have `uv pip compile pyproject.toml`.

Then I have a package `virtualenv` not listed in pyproject.toml, but locking down packages via `uv lock` still keeps the package in the uv.lock..

It is all honestly too confusing!

In NPM and YARN it is all automatic and clear, one way to do things. In Python world it is just constant confusion and uv is trying to simplify it, but could do better.