&gt; Maybe I&#x27;m not using it to it&#x27;s full potential.You aren&#x27;t, but that&#x27;s fine. Everyone has their own idea about how tooling should work and come together, and I happen to be in your camp (from what I can tell). I actively don&#x27;t want an all-in-one tool to do &quot;project management&quot;.

The dependencies descriptor is further structured, a requirements.txt is pretty raw in comparison.But where it isn&#x27;t a matter of opinion is, speed. Never met anyone who given then same interface, would prefer a process taking 10x longer to execute.

I agree flake8 -&gt; ruff was more of a game changer for me than pip+venv -&gt; uv. I use flake8&#x2F;ruff for more often than pip&#x2F;venv.uv is probably much more of a game changer for beginner python users who just need to install stuff and don&#x27;t need to lint. So it&#x27;s a bigger deal for the broader python ecosystem.

Idk, for me ruff was more of a game changer. No more explaining why we need both flake8 and pylint (and isort), no more flake8 plugins... Just one command that does it all.UV is great but I use it as a more convenient pip+venv. Maybe I&#x27;m not using it to it&#x27;s full potential.

This resonates so much. As someone who&#x27;s more on the builder&#x2F;product side than engineering, I&#x27;ve always felt that barrier with Python tooling. The learning curve for environment management has been one of those silent productivity killers.What strikes me about uv is that it seems to understand that not everyone launching a Python-based project has a CS degree. That accessibility matters—especially in the era where more non-engineers are building products.Curious: for those who&#x27;ve switched to uv, did you notice any friction when collaborating with team members who were still on traditional setups? I&#x27;m thinking about adoption challenges when you&#x27;re not a solo builder.

A very accessible and gentle introduction for the scientific set who may still be largely stuck on Conda. I liked it!

It’s definitely an issue for learning the language. Obviously after working with python a bit that doesn’t matter, but fragmentation still makes it more of a hassle to get open source projects up and running if they don’t use something close to your usual package management approach.

&gt; AnotherNo, the same uv that people have been regularly (<a href="https:&#x2F;&#x2F;hn.algolia.com&#x2F;?q=uv" rel="nofollow">https:&#x2F;&#x2F;hn.algolia.com&#x2F;?q=uv</a>) posting about on HN since its first public releases in February of 2024 (see e.g. <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39387641">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39387641</a>).&gt; How many are there now?Why is this a problem? The ecosystem has developed usable interoperable standards (for example, fundamentally uv manages isolated environments by using the same kind of virtual environment created by the standard library — because that&#x27;s the only kind that Python cares about; the key component is the `pyvenv.cfg` file, and Python is hard-coded to look for and use that); and you don&#x27;t have to learn or use more than one.There are competing options because people have different ideas about what a &quot;package manager&quot; should or shouldn&#x27;t be responsible for, and about the expectations for those tasks.

Another Python package manager? How many are there now?

Yeah I&#x27;ve never remotely had problems with venv and pip.

There have been actually many cases in my experience where venv simply worked but uv failed to install dependencies. uv is really fast but usually you need to install dependencies just once.

This is it. Later versions of python .11&#x2F;.12&#x2F;.13 have significant improvements and differences. Being able to seamlessly test&#x2F;switch between them is a big QOL improvement.I don&#x27;t love that UV is basically tied to a for profit company, Astral. I think such core tooling should be tied to the PSF, but that&#x27;s a minor point. It&#x27;s partially the issue I have with Conda too.

Yes. poetry &amp; pyenv was already a big improvement, but now uv wraps everything up, and additionally makes &quot;temporary environments&quot; possible (eg. `uv run --with notebook jupyter-notebook` to run a notebook with my project dependencies)Wonderful project

For me the biggest value of uv was replacing pyenv for managing multiple versions of python. So uv replaced pyenv+pyenv-virtualenv+pip

One thing that annoys me about Claude is that it doesn&#x27;t seem to create a venv by default when it creates a python project.  (But who knows, maybe 1&#x2F;3 of the time it does or something.)  But you have to ask each time to be sure.

Occasionally I have to build Python projects and coming from other languages and package managers, having to deal with a venv is super weird and annoying.

If that works for you, then that&#x27;s cool.  Personally, I don&#x27;t want to think about environments, and it&#x27;s weird that python is the only language that has venvs.  Having a tool that handles it completely transparently to me is ideal, to me.

&gt; I don’t really get that uv solves all these problems ve never encountered. Just make a venv and use it seems to work fine.For me package installation is way, way faster with uv, and I appreciate not needing to activate the virtual environment.

Venv seems pretty straightforward once you’ve learned the one activate command.I don’t really get that uv solves all these problems ve never encountered. Just make a venv and use it seems to work fine.

As someone who generally prefers not to use python in a production context (I think it&#x27;s excellent for one-off scripts or cron jobs that require more features then what bash provides), I agree with this sentiment. I recently wrote some python (using uv) and found it to be pleasant and well-integrated with a variety of LSPs.

The standard approach nowadays is to vendor the binaries, as e.g. Numpy does. This works just fine with pip.I&#x27;m interested if you have any technical documentation about how conda environments are structured. It would be nice to be able to interact with them. But I suspect the main problem is that if you use a non-conda tool to put something into a conda environment, there needs to be a way to make conda properly aware of the change. Fundamentally it&#x27;s the same issue as with trying to use pip in the system environment on Linux, which will interfere with the system package manager (leading to the PEP 668 protections).

I&#x27;m not sure if you&#x27;re aware, but there&#x27;s the Wheel Variants proposal [0] that the WheelNext initiative is working through that was presented at PyCon 2025 [1][2], which hopes to solve some of those problems.uv has implemented experimental support, which they announced here [3].[0] <a href="https:&#x2F;&#x2F;wheelnext.dev&#x2F;proposals&#x2F;pepxxx_wheel_variant_support&#x2F;" rel="nofollow">https:&#x2F;&#x2F;wheelnext.dev&#x2F;proposals&#x2F;pepxxx_wheel_variant_support...</a>[1] <a href="https:&#x2F;&#x2F;us.pycon.org&#x2F;2025&#x2F;schedule&#x2F;presentation&#x2F;100&#x2F;" rel="nofollow">https:&#x2F;&#x2F;us.pycon.org&#x2F;2025&#x2F;schedule&#x2F;presentation&#x2F;100&#x2F;</a>[2] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1Oki8vAWb1Q" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1Oki8vAWb1Q</a>[3] <a href="https:&#x2F;&#x2F;astral.sh&#x2F;blog&#x2F;wheel-variants" rel="nofollow">https:&#x2F;&#x2F;astral.sh&#x2F;blog&#x2F;wheel-variants</a>

I had this discussion briefly with a buddy who uses python exclusively for his career in austronomy. He was lamenting the pains of colaborting around Conda and seemed convinced it was irreplaceable. Being that I&#x27;m not familiar with the exact limitations Conda is providing for, Im curious if you could shed some insight here. Does nix not technically solve the issue? I understand this isn&#x27;t solely a technical problem and Nix adoption in this space isn&#x27;t likely, but I&#x27;m curious none-the-less!

You might be interested in Pixi: <a href="https:&#x2F;&#x2F;prefix.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;prefix.dev&#x2F;</a>
It uses uv under the hood for Python dependencies, while allowing you to also manage Conda dependencies in the same manifest (pixi.toml). The ergonomics are really nice and intuitive imo, and we&#x27;re on our way to replace our Poetry and Conda usage with only Pixi for Python&#x2F;C++ astrodynamics projects. The workspace-centric approach along with native lockfiles made most of our package management issues go away. I highly recommend it!
(Not affiliated anyhow, other than contributing with a simple PR for fun)

The best thing to happen to the Python ecosystem would be something that unites pip and conda. Conda is not going anywhere given how many packages depend on non-python binaries, especially in enterprise settings.

&gt; Seems like everything that would benefit from it is already written in highly optimized native modulesOr by asyncio.

I second and third this. I HATE python but uv was what made it usable to me. No other language had such a confusing obnoxious setup to do anything with outside of js land. uv made it sane for me.

As far as impact on the ecosystem I’d say uv is up there. For the language itself you are right. Curious if you’ve come across any real use cases for Gil-less python. I haven’t yet. Seems like everything that would benefit from it is already written in highly optimized native modules.

But there has been continual improvement over that time, both in the ecosystem, and in the language (like a syntax for generics).

And yet you still cannot write even moderately complex type expressions without severe pain.

Type annotations were introduced in 2008 and even type hints over decade ago in Sept 2015.

You can disable it, here&#x27;s the PEP, search has more digestible options<a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0703&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0703&#x2F;</a>

For sure, we see the same thing in the JS ecosystem. New tooling adds some feature, other options implement feature, convergence to a larger common set.I&#x27;m still mostly on poetry

The things you list may be a reason for some, but in all discussions I’ve had and read about on uv, the reason is that it behaves as a package manger should. It can just install dependencies from an automatically generated lockfile. It can update outdated minor versions. It can tell me about outdated versions of my dependencies. It can reproduce a build on another machine. The lock file can be put into version control. A coworker can run a single command to install everything. It abstracts the stupidity that is virtual environments away so much you don’t even have to touch them anymore. And also, it’s fast.Wake me up when pip can do any of that.

Things uv does better by pip by default:
- really hard to install a package globally by accident (pip: forgetting to activate venv)
- really easy to distinguish de and main dependencies (pip: create different files for different groups and set up their relationship)
- distinguish direct dependencies from indirect dependencies, making it easy to find when a package is not needed anymore (pip: I bet most devs are either not tracking sub dependencies or mixing all together with pip freeze)
- easily use different python versions for different projects (pip: not really)With uv it just works. With pip, technically you can make it work, and I bet you&#x27;ll screw something up along the way.

For that matter, IMX much of what people praise uv for is simply stuff that pip (and venv) can now do that it couldn&#x27;t back when they gave up on pip. Which in turn has become possible because of several ecosystem standards (defined across many PEPs) and increasing awareness and adoption of those standards.The &quot;install things that have complex non-Python dependencies using pip&quot; story is much better than several years ago, because of things like pip gaining a new resolver in 2020, but in large part simply because it&#x27;s now much more likely that the package you want offers a pre-built wheel (and that its dependencies also do). A decade ago, it was common enough that you&#x27;d be stuck with source packages even for pure-Python projects, which forced pip to build a wheel locally first (<a href="https:&#x2F;&#x2F;pradyunsg.me&#x2F;blog&#x2F;2022&#x2F;12&#x2F;31&#x2F;wheels-are-faster-pure-python&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pradyunsg.me&#x2F;blog&#x2F;2022&#x2F;12&#x2F;31&#x2F;wheels-are-faster-pure-...</a>).Another important change is that for wheels on PyPI the installer can now obtain separate .metadata files, so it can learn what the transitive dependencies are for a given version of a given project from a small plain-text file rather than having to speculatively download the entire wheel and unpack the METADATA file from it. (This is also possible for source distributions that include PKG-INFO, but they aren&#x27;t forced to do so, and a source distribution&#x27;s metadata is allowed to have &quot;dynamic&quot; dependencies that aren&#x27;t known until the wheel is built (worst case) or a special metadata-only build hook is run (requires additional effort for the build system to support and the developer to implement)).

You can get pretty darn close to static typing by using ty (from the same team as uv).I&#x27;ve been using it professionally and its been a big improvement for code quality.

typed annotations that are useful.Currently they are a bit pointless. Sure they aid in documentation, but they are effort and cause you pain when making modifications (mind you with halfarse agentic coding its probably less of a problem. )What would be better is to have a strict mode where instead of duck typing its pre-declared. It would also make a bunch of things faster (along with breaking everything and the spirit of the language)I still don&#x27;t get the appeal of UV, but thats possibly because I&#x27;m old and have been using pyenv and venv for many many years. This means that anything new is an attack on my very being.however if it means that conda fucks off and dies, then I&#x27;m willing to move to UV.

&gt; it&#x27;s just another package manager among manyIt&#x27;s the python version of fink vs macports vs homebrew. Or apt vs deb. or pkgsrc vs ports.But I don&#x27;t think &quot;its just another&quot; gets the value proposition here. It&#x27;s significantly simpler to deploy in practice for people like me, writing ad hoc scripts and running git downloaded scripts and codelets.Yes, virtualenv and pip existed. No, they turned out to be a lot more fiddly to run in practice than UV.That UV is rust is funny, but not in a terrible way. The llvm compiler toolchain is written in C but compiles other languages. Using one language to do things for another language isn&#x27;t such a terrible outcome.I hope UV supplants the others. Not to disrespect their authors, but UV is better for end users. If its worse for package maintainers I think the UV authors should be told.

If you&#x27;ve ever used python on a project above a certain size (both lines of code and people who contribute to it), type annotations quickly become something you find useful.

One problem is when people store different types in the same variable, what type is it at the time I use it.Types save you cognitive effort and catch errors earlier, while writing code, not later when running or testing

I don&#x27;t want type annotations. Was kinda the point of Python not to deal with types.

I&#x27;d put type annotations and GIL removal above UV without a second thought. UV is still young and I hit some of those growing pains. While it is very nice, I&#x27;m not going to put it up there with sliced bread, it&#x27;s just another package manager among many

That doesn&#x27;t fix the core issue. You can put anything inside a .deb file, even preinstall script can send your ~&#x2F;.aws&#x2F;credentials to China. The core concern is getting a package that&#x27;s verified by a volunteer human to not contain anything malicious, and then getting that package into Debian repository or equivalent.

A malicious server could detect whether the user is actually running &quot;curl | sh&quot; instead of just &quot;curl&quot; and only serve a malicious shell script when the code is executed blindly. See this thread for reference: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17636032">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=17636032</a>

can&#x27;t you just do curl|more and then view what it&#x27;s going to do? Then, once you&#x27;re convinced, go back to curl|sh.&#x2F;just guessing, haven&#x27;t tried it

For small project open source with a CLI audience, why bother with an install script at all and not just provide tarballs&#x2F;ZIP files and assume that the CLI audience is smart enough to untarball&#x2F;unzip it to somewhere on their PATH?Also, many of the &quot;distribution&quot; tools like brew, scoop, winget, and more are just &quot;PR a YAML file with your zip file URL, name of your EXE to add to a PATH, and a checksum hash of the zip to this git repository&quot;. We&#x27;re about at a minimum effort needed to generate a &quot;distribution&quot; point in software history, so seems interesting shell scripts to install things seem to have picked up instead.

Part of writing software involves writing a way to deploy that software to a computer. Piping a web URL to a bash interpreter is not good enough. if that&#x27;s the best installer you can do the rest of your code is probably trash.

&gt; Maybe if you trust the software, then trusting the install script isn&#x27;t that big of a stretch?The software is not written in a scripting language where forgetting quote marks regularly causes silent `rm -rf &#x2F;` incidents. And even then, I probably don&#x27;t explicitly point the software at my system root&#x2F;home and tell it to go wild.

While I do share the sentiment, I firmly believe that for opensource, no one should require the author to distribute their software, or even ask them to provide os-specific installation methods. They wrote it for free, use it or don&#x27;t. They provide a handy install script - don&#x27;t like it? sure, grab the source and build it yourself. Oops, you don&#x27;t know what the software does? Gotta read every line of it, right?Maybe if you trust the software, then trusting the install script isn&#x27;t that big of a stretch?

A package is at least a signable, checksummable artefact. The curl | sh thing could have been anything and after running it you have no record of what it was you did.There have also been PoCs on serving malicious content only when piped to sh rather than saved to file.If you want to execute shell code from the internet, at the very least store it in a file first and store that file somewhere persistent before executing it. It will make forensics easier

Security and auditability is not the core problem, it&#x27;s versioning and uninstalling. <a href="https:&#x2F;&#x2F;docs.sweeting.me&#x2F;s&#x2F;against-curl-sh" rel="nofollow">https:&#x2F;&#x2F;docs.sweeting.me&#x2F;s&#x2F;against-curl-sh</a>

That is still checked for its signature, the only thing you bypass is the automatic download over HTTP and dependency resolution by default.

Installing an out-of-distro deb&#x2F;rpm&#x2F;msi&#x2F;dmg&#x2F;etc package is just as unsafe as curl|sh. Or even unsafer, as packages tend to require root&#x2F;admin.

That iwr|iex example is especially egregious because it hardcodes the PowerShell &lt;7.0 EXE name to include `-ExecutionPolicy Bypass`. So it&#x27;ll fail on Linux or macOS, but more importantly iwr|iex is already an execution bypass, so including a second one seems a red flag to me. (What else is it downloading?)Also, most reasonable developers should already be running with the ExecutionPolicy RemoteSigned, it would be nice if code signing these install script was a little more common, too. (There was even a proposal for icm [Invoke-Command] to take signed script URLs directly for a much safer alternative code-golfed version of iwr|iex. Maybe that proposal should be picked back up.)

for real. You want to pipe a random URL to my bash interpreter to install?no. thats how you get malware. Make a package. Add it to a distro. then we will talk.

What would you suggested as a recommend method of installation in 2025?You can `pip install uv` or manually download and extract the right uv-*.tar.gz file from github: <a href="https:&#x2F;&#x2F;github.com&#x2F;astral-sh&#x2F;uv&#x2F;releases" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;astral-sh&#x2F;uv&#x2F;releases</a>

How is it even different from running a pre compiled binary

curl|sh and iwr|iex chills my spine, no one should recommend these methods of installation in 2025. I&#x27;m against closed computers but I&#x27;m also against reckless install. Even without the security concerns these way of installation tends to put files in a whole random places making it hard to manage and cleanup.

If you’re executing a script from an untrusted source, you should be examining it anyway.  If it fails to execute because you haven’t installed the correct dependencies, that’s an inconvenience, not a lucky security benefit. You can write a reverse shell in Python with no dependencies and just a few lines of code.

If that’s your concern you should be auditing the script and the dependencies anyway, whether they’re in a lock file or in the script. It’s just as easy to put malicious stuff in a requirements.txt

uv can still be redirected to private PyPi mirror, which should be mandatory from security and reliability perspective anyway.

Is there anything new that uv gives you here though?If you don&#x27;t care about being ecosystem-compliant (and I am sure malware does not), it&#x27;s only a few lines of Python to download the code and eval it.

You’re about to run an untrusted python script. The script can do whatever it wants to your system. Dependencies are the least of your worries.

Would you feel better with a script containing eval(requests.get(“<a href="http:&#x2F;&#x2F;pypi.org&#x2F;foo.py" rel="nofollow">http:&#x2F;&#x2F;pypi.org&#x2F;foo.py</a>”)) ?It’s the script contents that count, not just dependencies.Deno-style dependency version pinning doesn’t solve this problem unless you check every hash.

&quot;&quot;&quot;
uv is straightforward to install. There are a few ways, but the easiest (in my opinion) is this one-liner command — for Linux and Mac, it’s:curl -LsSf <a href="https:&#x2F;&#x2F;astral.sh&#x2F;uv&#x2F;install.sh" rel="nofollow">https:&#x2F;&#x2F;astral.sh&#x2F;uv&#x2F;install.sh</a> | sh
&quot;&quot;&quot;Also isn&#x27;t great. But that&#x27;s how homebrew is installed, so ... shrug ... ?Not to bash uv&#x2F;homebrew, they are better than most _easy_ alternatives.

I didn&#x27;t see it in the comments, but FWIW you can choose specific dependencies. You can use regular [dependency specifiers](<a href="https:&#x2F;&#x2F;packaging.python.org&#x2F;en&#x2F;latest&#x2F;specifications&#x2F;dependency-specifiers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;packaging.python.org&#x2F;en&#x2F;latest&#x2F;specifications&#x2F;depend...</a>), see [PEP 723](<a href="https:&#x2F;&#x2F;packaging.python.org&#x2F;en&#x2F;latest&#x2F;specifications&#x2F;inline-script-metadata&#x2F;#inline-script-metadata" rel="nofollow">https:&#x2F;&#x2F;packaging.python.org&#x2F;en&#x2F;latest&#x2F;specifications&#x2F;inline...</a>).

If I were to put on my security hat, things like this give me shivers. It&#x27;s one thing if you control the script and specified the dependencies. For any other use-case, you&#x27;re trusting the script author to not install python dependencies that could be hiding all manner of defects or malicious intent.This isn&#x27;t a knock against UV, but more a criticism of dynamic dependency resolution. I&#x27;d feel much better about this if UV had a way to whitelist specific dependencies&#x2F;dependency versions.

If I download python project from someone on the same network as me and they have it written in a different python version to me and a requirements.txt I need all those things anyway.

You can constrain Python version: <a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0723&#x2F;#:~:text=requires-python" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0723&#x2F;#:~:text=requires-python</a>

I mean, if you use == constraints instead of &gt;= you can avoid getting different versions, and if you’ve used it (or other things which combined have a superset of the requirements) you might have everything locally in your uv cache, too.But, yes, python scripts with in-script dependencies plus uv to run them doesn&#x27;t change dependency distribution, just streamlines use compared to manual setup of a venv per script.

And electricity and running water and oh the inconvenience. How is this worse than getting a script file that expects you to install modules?

You can specify python version requirements in the comment, as the standard describes

&gt; uv will magically install and use the specified modules.As long as you have internet access, and whatever repository it&#x27;s drawing from is online, and you may get different version of python each time, ...

&gt; Based on the man page it doesn’t appear to be doing anything useful hereThe man page tells me:<pre><code> -S, --split-string=S
 process and split S into separate arguments; used to pass multi‐
 ple arguments on shebang lines
</code></pre>
Without that, the system may try to treat the entirety of &quot;uv run --script&quot; as the program name, and fail to find it. Depending on your env implementation and&#x2F;or your shell, this may not be needed.See also: <a href="https:&#x2F;&#x2F;unix.stackexchange.com&#x2F;questions&#x2F;361794" rel="nofollow">https:&#x2F;&#x2F;unix.stackexchange.com&#x2F;questions&#x2F;361794</a>

Without -S, `uv run --script` would be treated as a binary name (including spaces) and you will get an error like &quot;env: ‘uv run --script’: No such file or directory&quot;.-S causes the string to be split on spaces and so the arguments are passed correctly.

Why is the ‘-S’ argument to ‘env’ needed? Based on the man page it doesn’t appear to be doing anything useful here, and in practice it doesn’t either.

&gt; As long as yourlinux core utils have supported this since 2018 (coreutils 8.3), amusingly it is the same release that added `cp --reflink`. AFAIK I know you have to opt out by having `POSIX_CORRECT=1` or `POSIX_ME_HARDER=1` or `--pedantic` set in your environment. [1]freebsd core utils have supported this since 2008MacOS has basically always supported this.---1. Amusingly despite `POSIX_ME_HARDER` not being official a alrge swapt of core utils support it. <a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;prep&#x2F;standards&#x2F;html_node&#x2F;Non_002dGNU-Standards.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;prep&#x2F;standards&#x2F;html_node&#x2F;Non_002dGNU-Sta...</a>

As long as your `&#x2F;usr&#x2F;bin&#x2F;env` supports `-S`, yes.It will install and use distribution packages, to use PyPA&#x27;s terminology; the term &quot;module&quot; generally refers to a component of an import package. Which is to say: the names you write here must be the names that you would use in a `uv pip install` command, not the names you `import` in the code, although they may align.This is an ecosystem standard (<a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0723&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0723&#x2F;</a>) and pipx (<a href="https:&#x2F;&#x2F;pipx.pypa.io" rel="nofollow">https:&#x2F;&#x2F;pipx.pypa.io</a>) also supports it.

I wouldn&#x27;t be surprised if astral&#x27;s next product would be something like this. It&#x27;s so obvious and there would be much interest from the ML crowd.My current hobby language is janet. Creating a statically linked binary from a script in janet is trivial. You can even bring your own C libraries.

Zipapp comes close: <a href="https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;zipapp.html" rel="nofollow">https:&#x2F;&#x2F;docs.python.org&#x2F;3&#x2F;library&#x2F;zipapp.html</a>

Have you tried Nuitka?  It takes a little effort but it can compile your Python program to a single executable that runs without network access.

I use this but I hate it.I want to be able to ship a bundle which needs zero network access to run, but will run.It is still frustratingly difficult to make portable Python programs.

You can get uv to generate this and add dependencies to it, rather than writing it yourself.

I also recommend the flag for a max release date for $current_date - that basically locks all package versions to that date without a verbose lock file!(sadly, uv cannot detect the release date of some packages. I&#x27;m looking at you, yaml!)

This is a PEP and not specific to uv: <a href="https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0723&#x2F;" rel="nofollow">https:&#x2F;&#x2F;peps.python.org&#x2F;pep-0723&#x2F;</a>

Is that a dare? &#x2F;sSmall price to pay for escaping python dependency hell.

&gt; The script now works like a standalone executableBut whoever runs this has to install uv first, so not really standalone.

Yeah, tried it with some rest client + pyfzf (CLI swagger UI sort of), it was really fun. Near instant dependency handling.. pretty cool

You don&#x27;t have to remember this, instead remember `uv init --script myscript.py`

For single-file Python scripts, which 99% of mine seem to be, you can simplify your life immensely by just putting this at the top of the script:<pre><code> #!&#x2F;usr&#x2F;bin&#x2F;env -S uv run --script
 # &#x2F;&#x2F;&#x2F; script
 # requires-python = &quot;&gt;=3.11&quot;
 # dependencies = [ &quot;modules&quot;, &quot;here&quot; ]
 # &#x2F;&#x2F;&#x2F;
</code></pre>
The script now works like a standalone executable, and uv will magically install and use the specified modules.

It&#x27;s still annoying to fork and they will probably try to move it to their own pypi service so it won&#x27;t be possible to do that.

You say this on a message board run by a VC about a programming language that is primarily developed by meta, google and co.uv is MIT licensed so if they rug pull, you can fork.

&gt; Pypa does not make good stuff or make good decisions.yep, I&#x27;ve been saying this for years, and astral have proved it in the best way: with brilliant, working softwarepython was a dying project 10 years ago, after the python 3000 debaclethe talent left&#x2F;lost interestthen the machine learning thing kicked off (for some reason using python), and now python is everywhere and suddenly massively importantand the supporting bureaucracies, still in their death throes, are unable to handle a project of its importance

This is going to sound harsh, but the problem with hatch is that it&#x27;s pypa. And look at all the people that equate python-the-language with problems in pypa-managed solutions already. Pypa does not make good stuff or make good decisions.Speaking of history, I was very sympathetic to the &quot;we are open-source volunteers, give us a break&quot; kind of stuff for the first N years.. but pypa has a pattern of creating problems, ignoring them, ignoring criticism, ignoring people who are trying to help, and pushing talent+interest elsewhere. This has fragmented the packaging ecosystem in a way that confuses newcomers, forces constant maintenance and training burden on experts, and damages the credibility of the language and its users. Hatch is frankly too little too late, and even if it becomes a wonderful standard, it would just force more maintenance, more confusion for a &quot;temporary&quot; period that lasts many, many years. Confidence is too far gone.As mentioned elsewhere in the thread, there are tons of conflicting tools in the space already, and due to the fragmentation, poetry etc could never get critical mass. That&#x27;s partly because pypa stuff felt most &quot;official&quot; and a safer long term bet than anything else, but partly because 33% better was never good enough to encourage widespread adoption until it was closer to 200% better. But uv actually IS that much better. Just let it win.And let pypa be a case-study in how to NOT do FOSS. Fragmentation is fine up to a point, but you know what? If it wasn&#x27;t for KDE &#x2F; Gnome reinventing the wheel for every single kind of individual GUI then we&#x27;d have already seen the glorious &quot;year of the linux desktop&quot; by now.

Seems like a commercial blog. And imho hatch is better from a Foss perspective.UV means getting more strings attached with VC funded companies and leaning on their infrastructure. This is a high risk for any FOSS community and history tells us how this ends….

yeah, I&#x27;ve moved away from it too, but that&#x27;s a great tool. A rush of rust tools is the best thing that happened to python in the decade

uv&#x27;s pip interface is like dipping one toe in the bathtub. Take a minute and try on the full managed interface instead: <a href="https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;concepts&#x2F;projects&#x2F;dependencies" rel="nofollow">https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;concepts&#x2F;projects&#x2F;dependencies</a>. Your commands then become:- uv add &lt;package_name&gt;- uv sync- uv run &lt;command&gt;Feels very ergonomic, I don&#x27;t need to think much, and it&#x27;s so much faster.

I mean I’ve had quite awful bugs from using pip pyenv and venv at the same time

What problems do you encounter using it with Docker?

Python versions and environments can be solved in more reliable abstraction level as well, e.g. if you are heavy Nix user.

Yeah, I agree. In particular it seems insane to me that virtualenv should have to exist. I can&#x27;t see any valid use case for a machine-global pool of dependencies. Why would anyone think it should be a separate tool rather than just the obvious thing that a dependency manager does? I say this as someone with nearly 20 years of Python experience.It&#x27;s the same sort of deal with pyenv--the Python version is itself a dependency of most libraries, so it&#x27;s a little silly to have a dependency manager that only manages some dependencies.

&quot;other languages don&#x27;t have 3 different tools for this.&quot; But other languages DO have 3 different tools so we should do that too!

I think OP&#x27;s complaint is rather that using `uv` is leaky: now you need to learn all the underlying stuff AND uv as well.The alternative, of course, is having Python natively support a combined tool. Which you can support while also not liking `uv` for the above reason.

Your implication is that pyenv, virtualenv, and pip should be 3 different tools. But for the average developer, these tools are all related to managing the python environment and versions which in my head sounds like one thing. Other languages don&#x27;t have 3 different tools for this.pip and virtualenv also add a ton of complexity and when they break (which happens quite often) debugging it is even harder despite them being &quot;battle tested&quot; tools.

&gt; 1. It tries to do too many things. Please just do one thing and do it well. It&#x27;s simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command.In my experience it generally does all of those well. Are you running into issues with the uv replacements?&gt; 2. You end up needing to use `uv pip` so it&#x27;s not even a full replacement for pip.What do end up needing to use `uv pip` for?

What are you needing to use `uv pip` for? I don&#x27;t think I ever call into pip from uv for anything nowadays. I typically just need to do `uv sync` and `uv run`, maybe sometimes `uvx` if I want to run some random 3rd party python script

Pixi is an alternative that you may want to try.

&gt; I had been hoping someone would introduce the non-virtualenv package management solution that every single other language has where there&#x27;s a dependency list and version requirements (including of the language itself) in a manifest file (go.mod, package.json, etc) and everything happens in the context of that directory alone without shell shenanigans.Isn&#x27;t that exactly a pyproject.toml via the the uv add&#x2F;sync&#x2F;run interface? What is that missing that you need?

In most cases, you don&#x27;t really need to manage virtual envs though ? uv commands that need a venv will just create one for you or install to the existing one automatically.

&gt; I had been hoping someone would introduce the non-virtualenv package management solution that every single other language has where there&#x27;s a dependency list and version requirements (including of the language itself) in a manifest file (go.mod, package.json, etc) and everything happens in the context of that directory alone without shell shenanigans.If you are using uv, you don’t need to do shell shenanigans, you just use uv run. So I&#x27;m not sure how uv with pyproject.toml doesn&#x27;t meet this description (yes, the venv is still there, it is used exactly as you describe.)

Really sounds like you&#x27;re using it wrong, no? I completely forgot about virtualenvs, pip and requirements.txt since I start using UV.

&gt; 2. You end up needing to use `uv pip` so it&#x27;s not even a full replacement for pip.Needing pip and virtualenvs was enough to make me realize uv wasn&#x27;t what I was looking for. If I still need to manage virtualenvs and call pip I&#x27;m just going to do so with both of these directly.I had been hoping someone would introduce the non-virtualenv package management solution that every single other language has where there&#x27;s a dependency list and version requirements (including of the language itself) in a manifest file (go.mod, package.json, etc) and everything happens in the context of that directory alone without shell shenanigans.

What&#x27;s your use case for UV_NO_SYNC? I assume the option exists for a reason, but aside from maybe a modest performance improvement when working with a massive complex package environment, I&#x27;m not sure what problem it solves.

I would also add UV_NO_SYNC as smth I had to learn. It comes in combination with uv pip

What do you mean it doesn&#x27;t play well with docker?

uv pip is a full reimplementation of pip. Way faster, better caching, less disk usage. What&#x27;d not to like about it?

&gt; It tries to do too many things. Please just do one thing and do it well.I disagree with this principle. Sometimes what I need is a kitset. I don&#x27;t want to go shopping for things, or browse multiple docs. I just want it taken care of for me. I don&#x27;t use uv so I don&#x27;t know if the pieces fit together well but the kitset can work well and so can a la carte.

&gt; 1. It tries to do too many things. Please just do one thing and do it well. It&#x27;s simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command.I think there are more cases where pip, pyenv, and virtualenv are used together than not. It makes sense to bundle the features of the three into one. uv does not replace ruff.&gt; 2. You end up needing to use `uv pip` so it&#x27;s not even a full replacement for pip.uv pip is there for compatibility and to facilitate migration but once you are full on the uv workflow you rarely need `uv pip` if ever&gt; 3. It does not play well with Docker.In what sense?&gt; 4. It adds more complexity. You end up needing to understand all of these new environmental variables: `UV_TOOL_BIN_DIR`, `UV_SYSTEM_PYTHON`, `UV_LINK_MODE`, etc.You don&#x27;t need to touch them at all

There is an optional &amp; experimental code formatting tool within uv (that just downloads riff), which is what OP may be referring to: <a href="https:&#x2F;&#x2F;pydevtools.com&#x2F;blog&#x2F;uv-format-code-formatting-comes-to-uv-experimentally&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pydevtools.com&#x2F;blog&#x2F;uv-format-code-formatting-comes-...</a>

&gt; It tries to do too many things. Please just do one thing and do it well. It&#x27;s simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command.uv doesn’t try to replace ruff.&gt; You end up needing to use `uv pip` so it&#x27;s not even a full replacement for pip.&quot;uv pip&quot; doesn&#x27;t use pip, it provides a low-level pip-compatible interface for uv, so it is, in fact, still uv replacing pip, with the speed and other advantages of uv when using that interface.Also, while I’ve used uv pip and uv venv as part of familiarizing myself with the tool, I’ve never run into a situation where I need either of those low-level interfaces rather than the normal high-level interface.&gt; It does not play well with Docker.How so?

It&#x27;s still one tool to orchestrate and run everything, which is preferable to many.

Yeah, I&#x27;m with you. I&#x27;m forcing myself to learn it because it looks like that&#x27;s the way PyWorld is going. I don&#x27;t dislike uv as much as poetry. But I guess I never really ran into issues using pyenv and pip. shrug Maybe I wasn&#x27;t working on complex enough projects.

&gt; You end up needing to use `uv pip` so it&#x27;s not even a full replacement for pip.No you don&#x27;t. That&#x27;s just a set of compatibility approaches for people who can&#x27;t let go of pip&#x2F;venv. Move to uv&#x2F;PEP723, world&#x27;s your oyster.&gt; It does not play well with Docker.Huh? I use uv both during container build and container runtime, and it works just fine?&gt; You end up needing to understand all of these new environmental variablesNot encountered the need for any of these yet. Your comments on uv are so far out of line of all the uses I&#x27;ve seen, I&#x27;d love to hear what you&#x27;re specifically doing that these become breaking points.

Slow doesn&#x27;t really begin to do justice, I&#x27;d have to wait for &gt;5 minutes for pipenv to finish figuring out our lock file. uv does it in less than a second.

What doesn’t just work about uv in particular? You basically need three commands - uv add, uv sync, and uv run. Forget about virtual environments, and get back to working. No configuration necessary.

&gt; Pipenv is just straightforward and “just works”I have worked on numerous projects that started with pipenv and it has never &quot;just works&quot; ever. Either there&#x27;s some trivial dependency conflict that it can&#x27;t resolve or it&#x27;s slow as molasses or something or the other. pipenv has been horrible to use. I started switching projects to pip-tools and now I recommend using uv

This. I was researching uv to replace my pipenv+pyenv setup, but after reading up a bit I decided to just give up. Pipenv is just straightforward and “just works”. Aside from being slow, not much is wrong with it. I’m not in the mood to start configuring uv, a tool that should take me 2 minutes and a “uv —-help” to learn.

If your pyproject.toml is setup properly you shouldn&#x27;t need to use `uv pip` at all.I&#x27;m using uv in two dozen containers with no issues at all. So not sure what you mean that it doesn&#x27;t play well with Docker.

So I have been doing Python for far too long and have all sort of tooling I&#x27;ve accreted to make Python work well for me across projects and computers and I never quite made the leap to Poetry and was suspicious of uv.Happened to buy a new machine and decided to jump in the deep end and it&#x27;s been glorious. I think the difference from your comment (and others in this chain) and my experience is that you&#x27;re trying to make uv fit how you have done things. Jumping all the way in, I just . . . never needed virtualenvs. Don&#x27;t really think about them once I sorted out a mistake I was making. uv init and you&#x27;re pretty much there.&gt;You end up needing to use `uv pip` so it&#x27;s not even a full replacement for pipThe only time I&#x27;ve used uv pip is on a project at work that isn&#x27;t a uv-powered project. uv add should be doing what you need and it really fights you if you&#x27;re trying to add something to global because it assumes that&#x27;s an accident, which it probably is (but you can drop back to uv pip for that).&gt;`UV_TOOL_BIN_DIR`, `UV_SYSTEM_PYTHON`, `UV_LINK_MODE`, etc.I&#x27;ve been using it for six months and didn&#x27;t know those existed. I would suggest this is a symptom of trying to make it be what you&#x27;re used to. I would also gently suggest those of us who have decades of Python experience may have a bit of Stockholm Syndrome around package management, packaging, etc.

uv has played well with Docker in my experience, from dev containers to CI&#x2F;CD to production image builds. Would be interested to hear what is not working for you.The uv docs even have a whole page dedicated to Docker; you should definitely check that out if you haven&#x27;t already: <a href="https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;guides&#x2F;integration&#x2F;docker&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;guides&#x2F;integration&#x2F;docker&#x2F;</a>

5. No concept of global&#x2F;shell&#x2F;local venv auto activation, so get used to typing &quot;uv run&quot;, or manually recreating these concepts, with shell stuffs.

It&#x27;s funny, I feel like half the reason I use docker is for python projects.

Yeah, I find that I like to use uv for one thing, quickly&#x2F;efficiently getting a Python into a new venv for some project. A la:<pre><code> uv venv ~&#x2F;.venvs&#x2F;my_new_project --python 3.13
 source ~&#x2F;.venvs&#x2F;my_new_project&#x2F;bin&#x2F;activate
 python3 -m ensurepip --upgrade
 cp -r &#x2F;path&#x2F;from&#x2F;source&#x2F;* .
 python3 -m pip install -r requirements.txt
</code></pre>
So here uv installs the Python version wanted. But it&#x27;s just a venv. And we pip install using requirements.txt, like normal, within that venv.Someone, please tell me what&#x27;s wrong with this. To me, this seems much less complicated that some uv-centric .toml config file, plus some uv-centric commands for more kinds of actions.

oh look, the average golang fan. here’s a challenge for you: explain _why_ the complexity is bad without:- resorting to logical fallacies, or- relying on your unstated assumption that all complexity is bad

When do you use `uv pip`? I never use it. It feels like an edge case only command.

We use it for many projects. None of these are true for us.Why do you need to use uv pip?What problems you have in Docker?I don&#x27;t understand any of those env variables you listed, yet I use uv without problems.

I must be the odd man out but I am not a fan of uv.1. It tries to do too many things. Please just do one thing and do it well. It&#x27;s simultaneously trying to replace pip, pyenv, virtualenv, and ruff in one command.2. You end up needing to use `uv pip` so it&#x27;s not even a full replacement for pip.3. It does not play well with Docker.4. It adds more complexity. You end up needing to understand all of these new environmental variables: `UV_TOOL_BIN_DIR`, `UV_SYSTEM_PYTHON`, `UV_LINK_MODE`, etc.

Personally, I prefer prepending `uv` to my commands because they&#x27;re more stateless that way. I don&#x27;t need to remember which terminal my environment is sourced in, and when copying and pasting commands to people I don&#x27;t need to worry about what state their terminal is it. It just works.

I agree, once I learned (early in my programming journey) what the PATH is as a concept, I have never had an environment problem.However, I also think many people, even many programmers, basically consider such external state &quot;too confusing&quot; and also don&#x27;t know how they&#x27;d debug such a thing. Which I think is a shame since once you see that it&#x27;s pretty simple it becomes a tool you can use everywhere. But given that people DON&#x27;T want to debug such, I can understand them liking a tool like uv.I do think automatic compiler&#x2F;interpreter version management is a pretty killer feature though, that&#x27;s really annoying otherwise typically afaict, mostly because to get non-system wide installs typically seems to require compiling yourself.

Yup. I never even use activate, even though that&#x27;s what you find in docs all over the place. Something about modifying my environment rubs me the wrong way. I just call ``.&#x2F;venv&#x2F;bin&#x2F;python driver.py`` (or ``.&#x2F;venv&#x2F;bin&#x2F;driver`` if you install it as a script) which is fairly self-evident, doesn&#x27;t mess with your environment, and you can call into as many virtualenvs as you need to independently from one another.``uv`` accomplishes the same thing, but it is another dependency you need to install. In some envs it&#x27;s nice that you can do everything with the built-in Python tooling.

If you have multiple python applications with different versions, it&#x27;s nice to use the same version as deployed.At least major and minor, patch is rarely needed for python.

I would very much like to know the reason why they named it bin&#x2F; here and Scripts&#x2F; there. To get some closure.

&gt;&gt; I also like how you can manage Python versions very easily with it.
&gt;
&gt; I still don&#x27;t understand why people value this so highly, but so it goes.Well I do need some way to install multiple python versions in parallel, and ideally the correct python version would be used in each project automatically. I used to use pyenv for this, which puts shims in your path so that it can determine which python executable to run on the fly, but I found that it was sometimes very slow, and it didn’t work seamlessly with other tools. Specifically pipenv seemed to ignore it, so I’d have to use a workaround to point pipenv to the path to the pyenv-installed python executable.When one tool does both python installs and dependency&#x2F;venv management, then it can make these work seamlessly together, and I don’t need to screw up my path to make the version selection work either.

&gt; how much I prefer prepending &quot;uv&quot; to everything instead of activating environmentsYou can also prepend the path to the virtual environment&#x27;s bin&#x2F; (or Scripts&#x2F; on Windows). Literally all that &quot;activating an environment&quot; does is to manipulate a few environment variables. Generally, it puts the aforementioned directory on the path, sets $VIRTUAL_ENV to the venv root, configures the prompt (on my system that means modifying $PS1) as a reminder, and sets up whatever&#x27;s necessary to undo the changes (on my system that means defining a &quot;deactivate&quot; function; others may have a separate explicit script for that).I personally don&#x27;t like the automatic detection of venvs, or the pressure to put them in a specific place relative to the project root.&gt; I also like how you can manage Python versions very easily with it.I still don&#x27;t understand why people value this so highly, but so it goes.&gt; the inevitable bi-yearly &quot;debug a Python environment day&quot;If you&#x27;re getting this because you have venvs based off the system Python and you upgrade the system Python, then no, uv can&#x27;t do anything about that. Venvs aren&#x27;t really designed to be relocated or to have their underlying Python modified. But uv will make it much faster to re-create the environment, and most likely that will be the practical solution for you.

There are basically 0 other programming languages that use the &quot;directory&#x2F;shell integration activated virtual environment&quot;, outside of Python.How does the rest of the world manage to survive without venvs? Config files in the directory. Shocking, really :-)))

It does, Python has essentially solved it for years.

This isn&#x27;t a comment just about Python.. but it should just work.  There shouldn&#x27;t be constant ceremony for getting and keeping environments running.

I use mise with uv to automatically activate a project&#x27;s venv but prefixing is still useful sometimes since it would trigger a sync in case you forgot to do it.

This is a key tenets of venvs generally, uv didn&#x27;t invent anything, it simply brought them under one roof and improved perf.

One of the key tenets of uv is virtualenvs should be disposable. So barring any bugs with uv there should never be any debugging environments. Worst case just delete .venv and continue as normal.

I&#x27;m surprised by how much I prefer prepending &quot;uv&quot; to everything instead of activating environments - which is still naturally an option if that&#x27;s what floats your boat.I also like how you can manage Python versions very easily with it. Everything feels very &quot;batteries-included&quot; and yet local to the project.I still haven&#x27;t used it long enough to tell whether it avoids the inevitable bi-yearly &quot;debug a Python environment day&quot; but it&#x27;s shown enough promise to adopt it as a standard in all my new projects.

Take a look at their upcoming product Pyx to see where revenue can start to come in for paid&#x2F;hosted services.<a href="https:&#x2F;&#x2F;astral.sh&#x2F;pyx" rel="nofollow">https:&#x2F;&#x2F;astral.sh&#x2F;pyx</a>

That doesn&#x27;t really seem like a way to avoid getting &quot;Broadcommed.&quot; Vertically integrated tooling is kind of a commodity.

It doesn&#x27;t seem to answer to anything.

hmm how well did that work for Docker ...

From &quot;So how does Astral plan to make money?
&quot; (<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44358216">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=44358216</a>):&quot;What I want to do is build software that vertically integrates with our open source tools, and sell that software to companies that are already using Ruff, uv, etc. Alternatives to things that companies already pay for today. An example of what this might look like [...] would be something like an enterprise-focused private package registry.&quot;There&#x27;s also this interview with Charlie Marsh (Astral founder): <a href="https:&#x2F;&#x2F;timclicks.dev&#x2F;podcast&#x2F;supercharging-python-tooling-an-interview-with-charlie-marsh" rel="nofollow">https:&#x2F;&#x2F;timclicks.dev&#x2F;podcast&#x2F;supercharging-python-tooling-a...</a> (specifically the &quot;Building a commerical company with venture capital
&quot; section)

Conda apparently makes a ton of money just by selling access to &quot;more secure&quot; packages, so maybe they&#x27;ll do something like that.There are apparently 10 million Python developers in the world and pretty soon all of them will be using uv. I doubt it is that hard to monetise.

It doesn&#x27;t really matter that it&#x27;s Rust. npm is written in JS.

These rust based tools really change the idea of what&#x27;s possible (when you can get feedback in milliseconds). But I&#x27;m trying to figure out what Astral as a company does for revenue. I don&#x27;t see any paid products on their website. They even have investors.So far it seems like they have a bunch of these high performance tools. Is this part of an upcoming product suite for python or something? Just curious. I&#x27;m not a full-time python developer.

The speed is quite believable. Reinstalling packages from a cache should be extremely fast. Pip suffers from poor architecture.

They have different use cases. uv is meant to be the singular tool for managing Python packages and dependencies, replacing pip, virtualenv, and pip-tools. Conda is for more general-purpose environment management, not just Python. If you&#x27;re doing something with Node or R, uv won&#x27;t work at all because it&#x27;s only for Python.uv&#x27;s biggest advantage is speed. It claims a 10-100x performance speedup over pip and Conda [1]. uv can also manage python versions and supports using Python scripts as executables via inline dependencies [2].But Conda is better for non-Python usage and is more mature, especially for data science related uses.[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;astral-sh&#x2F;uv&#x2F;blob&#x2F;main&#x2F;BENCHMARKS.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;astral-sh&#x2F;uv&#x2F;blob&#x2F;main&#x2F;BENCHMARKS.md</a>
[2]: <a href="https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;#scripts" rel="nofollow">https:&#x2F;&#x2F;docs.astral.sh&#x2F;uv&#x2F;#scripts</a>

Genuinely trying to learn here - what&#x27;s the major advantage of using uv over conda?(Transparently, I&#x27;m posting this before I&#x27;ve completed the article.)

&gt; What does uv do in order to resolve dependencies much faster?- Representing version numbers as single integer for fast comparison.- Being implemented in rust rather than Python (compared to Poetry)- Parallel downloads- Caching individual files rather than zipped wheel, so installation is just hard-linking files, zero copy (on unix at least). Also makes it very storage efficient.

&gt; because new poetry releases would stall trying to resolve dependencies.&gt; uv is much faster than both of these toolsconda is also (in)famous for being slow at this, although the new mamba solver is much faster. What does uv do in order to resolve dependencies much faster?

Can&#x27;t agree more. We were using pyenv+poetry before and regularly had to pin our poetry version to a specific one, because new poetry releases would stall trying to resolve dependencies.pyenv was problematic because you needed the right concoction of system packages to ensure it compiled python with the right features, and we have a mix of MacOS and Linux devs so this was often non-trivial.uv is much faster than both of these tools, has a more ergonomic CLI, and solves both of the issues I just mentioned.I&#x27;m hoping astral&#x27;s type checker is suitably good once released, because we&#x27;re on mypy right now and it&#x27;s a constant source of frustration (slow and buggy).

Node has at least bun, and probably other tools, that attempt to speed things up in similar ways. New tooling is always coming for our languages of choice, even if we aren&#x27;t paying attention.

well there&#x27;s npm, pnpm, yarn, bun package managersnot a python developer, so not sure it&#x27;s equivalent as the npm registry is shared between all.

&gt; There’s pip, virtualenv, pipx, uv, probably half a dozen others I’m missing...&gt; Reminds me of that competing standards xkcd.Yes, for years I&#x27;ve sat on the sidelines avoiding the fragmented Poetry, ppyenv, pipenv, pipx, pip-tools&#x2F;pip-compile, rye, etc, but uv does now finally seem to be the all-in-one solution that seems to be succeeding where other tools have failed.

&gt; I see a python app on GitHub and they’re all listing different package management tools.In general, you can use your preferred package management tool with their code. The developers are just showing you their own workflow, typically.

I find the python tooling so confusing now. There’s pip, virtualenv, pipx, uv, probably half a dozen others I’m missing. I like node, npm isolates by default, npx is easy to understand, and the ecosystem is much less fragmented. I see a python app on GitHub and they’re all listing different package management tools. Reminds me of that competing standards xkcd.

Ty is still under very active development, so it either works or very much doesn&#x27;t. I run it occasionally to see if it works on my codebases, and while it is getting closer, it isn&#x27;t quite there yet.Definitely lightyears faster than mypy though.

I&#x27;m waiting for ty to get TypedDict checking. <a href="https:&#x2F;&#x2F;github.com&#x2F;astral-sh&#x2F;ty&#x2F;issues&#x2F;154" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;astral-sh&#x2F;ty&#x2F;issues&#x2F;154</a>

Everything from the astral team has been superb, I don&#x27;t want to use Python without ruff &amp; uv. Yet to try &quot;ty&quot;, anyone used it?

Wait til you find out what CPython is written in.

Care to share with the group what’s so hilarious?

There is something hilarious about using a project&#x2F;package manager written in another language.

I am still learning and I have the same feeling as someone who don&#x27;t consider myself good with python. At least I can keep my venv in control now is all I can feel with Uv approach.

I don&#x27;t like that it defaults to putting the virtual environment right there, I much prefer how pipenv does it with a shared one in the users home directory, but it&#x27;s a small price to pay for how fast it is.

There is also pixi (which uses uv for the python side of things) which feels like uv for conda.

conda (and its derivatives that are also “conda” now), and conda-forge specifically, are the best ways to install things that will work across operating systems, architectures, and languages - without having to resort to compiling everything.Want to make sure a software stack works well on a Cray with MPI+cuda+MKL, macOS, and ARM linux, with both C++ and Python libraries? It’s possible with conda-forge.

As far as I get it, conda is still around because uv is focused on python while conda handles things written in other languages. Unless uv gets much more universal than expected, conda is here to stay.

This is something that uv advocates should pay attention to, there are always contexts that need different assumptions, especially with our every growing and complex pile of libraries and systems.

Pixi has also been such a breathe of fresh air for me. I think it&#x27;s as big of a deal as UV (It uses UV under the hood for the pure python parts).It&#x27;s still very immature but if you have a mixture of languages (C, C++, Python, Rust, etc.) I highly recommend checking it out.

Yep, pixi is game changing. Especially for AI&#x2F;ML, the ability to deal with non-python dependencies in nearly as fast a way as `uv` is huge. We have some exciting work leveraging the lower level primatives pixi uses we hope to share more about soon.

I wish the Python ecosystem would just switch to Rust. Things are nice over here… please port your packages to crates.

This seems to pretty much cover the same use cases as Mise. Is that true?

Pixi is what FreeCAD is now using. (Along with Rattler).It makes building FreeCAD pretty trivial, which is a huge deal considering FreeCAD’s really complex Python and non-python, cross-platform dependencies.

You might be interested in pixi, which is roughly to conda as uv is to pip (also written in Rust, it reuses the uv solver for PyPI packages)

I&#x27;d argue bzip compression was a mistake for Conda.  There was a time when I had Conda packages made for the CUDA libraries so conda could locally install the right version of CUDA for every project,  but boy it took forever for Conda to unpack 100MB+ packages.

uv does it by caching versions of packages so they can be shared across projects&#x2F;environments. So you still have to store those multi-gig directories but you don&#x27;t have so much duplication. If conda could do something similar that would be great

It would be nice indeed if there was a good solution to multi-gigabyte conda directories. Conda has been reproducible in my experience with pinned dependencies in the environment YAML... slow to build, sure, but reproducible.

It&#x27;s still used in edu and research. Haven&#x27;t seen it in working environments in quite some time as well.

At least on my cluster, few if any workloads are containerized.  We also have an EKS where folks run containerized, but that&#x27;s more inference and web serving, rather than training.

Very common in education&#x2F;research systems. Even the things which are containerised often have conda in them.

&gt; I work professionally in ML and have not had to touch conda in the last 7 years. In an ML cluster, it is hopefully containerized and there is no need for that?I wish my life had been like this. Unfortunately I always appear to end up needing to make this stuff work for everyone else (the curse of spending ten years on Linux, I suppose).But then ML is a very broad church, and particularly if you&#x27;re a researcher in a bigger company then I could see this being true for lots of people (again, i wish this was me).

I work professionally in ML and have not had to touch conda in the last 7 years. In an ML cluster, it is hopefully containerized and there is no need for that?

the topic of managing large dependency chains for ML&#x2F;AI workloads in a reproducible has been a deep rabbit hole for us. if you are curious, here is some of the work in open domain<a href="https:&#x2F;&#x2F;docs.metaflow.org&#x2F;scaling&#x2F;dependencies" rel="nofollow">https:&#x2F;&#x2F;docs.metaflow.org&#x2F;scaling&#x2F;dependencies</a>
<a href="https:&#x2F;&#x2F;outerbounds.com&#x2F;blog&#x2F;containerize-with-fast-bakery" rel="nofollow">https:&#x2F;&#x2F;outerbounds.com&#x2F;blog&#x2F;containerize-with-fast-bakery</a>

I&#x27;ve programmed all those languages before (learned C in &#x27;87, C++ in 93, Go in 2015 or so) and to be honest, while I still love C, I absolutely hate what C++ has become, Go never appealed to me (they really ignored numeric work for a long time).  Rust feels like somebody wanted to make a better C with more standard libraries, without going the crazy path C++ took.

Obligatory: Not only rust would be faster than python, but Rust definitely makes it easy with Cargo. Go, C, C++ should all exhibit the performance you are seeing in uv, if it had been written in one of those languages.The curmudgeon in me feels the need to point out that fast, lightweight software has always been possible, it&#x27;s just becoming easier now with package managers.

I&#x27;d be interested in this too.  I know it&#x27;s possible, but haven&#x27;t found a good guide on how to do it well and manage the multi-lang complexity.

Have you found it easy to write rust modules with python interfaces?  What tools do you recommend?

I hadn&#x27;t paid any attention to rust before uv, but since starting to use uv, I&#x27;ve switched a lot of my performance-sensitive code dev to rust (with interfaces to python). These sorts of improvements really do improve my quality of life significantly.My hope is that conda goes away completely. I run an ML cluster and we have multi-gigabyte conda directories and researchers who can&#x27;t reproduce anything because just touching an env breaks the world.

Uv is the best thing to happen to the Python ecosystem in a decade