[HN Gopher] Uv is the best thing to happen to the Python ecosyst...
___________________________________________________________________
Uv is the best thing to happen to the Python ecosystem in a decade
Author : todsacerdoti
Score : 794 points
Date : 2025-10-29 18:57 UTC (4 hours ago)
(HTM) web link (emily.space)
(TXT) w3m dump (emily.space)
| NewJazz wrote:
| 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'm
| not using it to it's full potential.
| zahlman wrote:
| > Maybe I'm not using it to it's full potential.
|
| You aren't, but that'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't want an
| all-in-one tool to do "project management".
| hirako2000 wrote:
| The dependencies descriptor is further structured, a
| requirements.txt is pretty raw in comparison.
|
| But where it isn't a matter of opinion is, speed. Never met
| anyone who given then same interface, would prefer a process
| taking 10x longer to execute.
| collinmanderson wrote:
| I agree flake8 -> ruff was more of a game changer for me than
| pip+venv -> uv. I use flake8/ruff for more often than pip/venv.
|
| uv is probably much more of a game changer for beginner python
| users who just need to install stuff and don't need to lint. So
| it's a bigger deal for the broader python ecosystem.
| languagehacker wrote:
| A very accessible and gentle introduction for the scientific set
| who may still be largely stuck on Conda. I liked it!
| Animats wrote:
| _Another_ Python package manager? How many are there now?
| zahlman wrote:
| > Another
|
| No, the same uv that people have been regularly
| (https://hn.algolia.com/?q=uv) posting about on HN since its
| first public releases in February of 2024 (see e.g.
| https://news.ycombinator.com/item?id=39387641).
|
| > 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'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't have to learn or use more than one.
|
| There are competing options because people have different ideas
| about what a "package manager" should or shouldn't be
| responsible for, and about the expectations for those tasks.
| andy99 wrote:
| 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.
| andrewstuart wrote:
| 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.
| bigstrat2003 wrote:
| Yeah I've never remotely had problems with venv and pip.
| nicce wrote:
| 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.
| athorax wrote:
| For me the biggest value of uv was replacing pyenv for managing
| multiple versions of python. So uv replaced pyenv+pyenv-
| virtualenv+pip
| Hasz wrote:
| This is it. Later versions of python .11/.12/.13 have
| significant improvements and differences. Being able to
| seamlessly test/switch between them is a big QOL improvement.
|
| I don'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's a minor point. It's partially the issue I
| have with Conda too.
| rkomorn wrote:
| Didn't Astral get created out of uv (and other tools),
| though? Isn't it fair for the creators to try and turn it
| into a sustainable job?
|
| Edit: or was it ruff? Either way. I thought they created
| the tools first, then the company.
| zahlman wrote:
| > Later versions of python .11/.12/.13 have significant
| improvements and differences. Being able to seamlessly
| test/switch between them is a big QOL improvement.
|
| I just... build from source and make virtual environments
| based off them as necessary. Although I don't really
| understand why you'd want to keep older _patch_ versions
| around. (The Windows installers don 't even accommodate
| that, IIRC.) And I can't say I've noticed any of those
| "significant improvements and differences" between patch
| versions ever mattering to my own projects.
|
| > I don'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's a minor point. It's partially the
| issue I have with Conda too.
|
| In my book, the less under the PSF's control, the better.
| The meager funding they do receive now is mostly directed
| towards making PyCon happen (the main one; others like
| PyCon Africa get a pittance) and to certain grants, and to
| a short list of paid staff who are generally speaking board
| members and other decision makers and _not_ the people
| actually developing Python. Even without considering
| "politics" (cf. the latest news turning down a grant for
| ideological reasons) I consider this gross mismanagement.
| philipallstar wrote:
| > I think such core tooling should be tied to the PSF, but
| that's a minor point.
|
| The PSF is busy with social issues and doesn't concern
| itself with trivia like this.
| gegtik wrote:
| Yes. poetry & pyenv was already a big improvement, but now uv
| wraps everything up, and additionally makes "temporary
| environments" possible (eg. `uv run --with notebook jupyter-
| notebook` to run a notebook with my project dependencies)
|
| Wonderful project
| philipallstar wrote:
| With uvx it also replaces pipx.
| projektfu wrote:
| One thing that annoys me about Claude is that it doesn't seem
| to create a venv by default when it creates a python project.
| (But who knows, maybe 1/3 of the time it does or something.)
| But you have to ask each time to be sure.
| cdmckay wrote:
| 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.
| nilamo wrote:
| If that works for you, then that's cool. Personally, I don't
| want to think about environments, and it'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.
| collinmanderson wrote:
| > 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.
| mgh95 wrote:
| As someone who generally prefers not to use python in a
| production context (I think it'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.
| curiousgal wrote:
| 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.
| zahlman wrote:
| The standard approach nowadays is to vendor the binaries, as
| e.g. Numpy does. This works just fine with pip.
|
| I'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'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).
| karlding wrote:
| I'm not sure if you're aware, but there'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]
| https://wheelnext.dev/proposals/pepxxx_wheel_variant_support...
|
| [1] https://us.pycon.org/2025/schedule/presentation/100/
|
| [2] https://www.youtube.com/watch?v=1Oki8vAWb1Q
|
| [3] https://astral.sh/blog/wheel-variants
| dugidugout wrote:
| 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'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't solely a technical problem and
| Nix adoption in this space isn't likely, but I'm curious none-
| the-less!
| Carbonhell wrote:
| You might be interested in Pixi: https://prefix.dev/ 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're on our way to replace our Poetry and Conda usage with
| only Pixi for Python/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)
| verdverm wrote:
| I'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'm not going to put it up there
| with sliced bread, it's just another package manager among many
| WD-42 wrote:
| 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.
| seabrookmx wrote:
| > Seems like everything that would benefit from it is already
| written in highly optimized native modules
|
| Or by asyncio.
| WD-42 wrote:
| I'm pretty ignorant about this stuff but I think asyncio is
| for exactly that, asynchronus I/O. Whereas GIL-less Python
| would be beneficial for CPU bound programs. My day job is
| boring so I'm never CPU bound, always IO bound on the
| database or network. If there is CPU heavy code, it's in
| Numpy. So I'm not sure if Gil-less actually helps there.
| nomel wrote:
| asyncio is unrelated to the parallelism prevented by the
| GIL.
| rustystump wrote:
| 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.
| giancarlostoro wrote:
| Node definitely needs its own "uv" basically.
| jampekka wrote:
| Why? Uv very good compared to other Python package
| managers, but even plain npm is still better than uv, and
| pnpm is a lot better.
| verdverm wrote:
| pnpm
| monkpit wrote:
| How is npm not exactly that?
| jampekka wrote:
| Type annotations were introduced in 2008 and even type hints
| over decade ago in Sept 2015.
| zacmps wrote:
| But there has been continual improvement over that time, both
| in the ecosystem, and in the language (like a syntax for
| generics).
| 9dev wrote:
| And yet you still cannot write even moderately complex type
| expressions without severe pain.
| brcmthrowaway wrote:
| What happend with GIL-removal
| verdverm wrote:
| You can disable it, here's the PEP, search has more
| digestible options
|
| https://peps.python.org/pep-0703/
| zahlman wrote:
| For that matter, IMX much of what people praise uv for is
| simply stuff that _pip (and venv) can now do_ that it couldn '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 "install things that have complex non-Python dependencies
| using pip" 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 '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'd be stuck with source packages _even for pure-Python
| projects_ , which forced pip to build a wheel locally first
| (https://pradyunsg.me/blog/2022/12/31/wheels-are-faster-
| pure-...).
|
| 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't forced to
| do so, and a source distribution's metadata is allowed to have
| "dynamic" dependencies that aren'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)).
| verdverm wrote:
| 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'm still mostly on poetry
| 9dev wrote:
| 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.
| zahlman wrote:
| > the reason is that it behaves as a package manger should.
|
| This is a matter of opinion. Pip exists to install the
| packages and their dependencies. It does not, by design,
| exist to manage a project for you.
| pnt12 wrote:
| 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'll screw something up along the way.
| zahlman wrote:
| > - really hard to install a package globally by accident
| (pip: forgetting to activate venv)
|
| This is different as of Python 3.11. Please see
| https://peps.python.org/pep-0668/ for details. Nowadays, to
| install a package globally, you first have to _have_ a
| global copy of pip (Debian makes you install that
| separately), then you have to intentionally bypass a
| security marker using --break-system-packages.
|
| Also, you don't have to activate the venv to use it. You
| can specify the path to the venv's pip explicitly; or you
| can use a different copy of pip (e.g. a globally-installed
| one) passing it the `--python` argument (you have been able
| to do this for about 3 years now).
|
| > - really easy to distinguish [dev] and main dependencies
|
| As of 25.1, pip can install from dependency groups
| described in pyproject.toml, which is the standard way to
| group your dependencies in metadata.
|
| > distinguish direct dependencies from indirect
| dependencies, making it easy to find when a package is not
| needed anymore
|
| As of 25.1, pip can create PEP 751 standard lockfiles.
|
| > easily use different python versions for different
| projects
|
| If you want something to install Python for you, yes, that
| was never in pip's purview, by design.
|
| If you want to use an environment based off an existing
| Python, that's what venv is for.
| KaiserPro wrote:
| 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't get the appeal of UV, but thats possibly because
| I'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'm
| willing to move to UV.
| KK7NIL wrote:
| You can get pretty darn close to static typing by using ty
| (from the same team as uv).
|
| I've been using it professionally and its been a big
| improvement for code quality.
| hollow-moe wrote:
| curl|sh and iwr|iex chills my spine, no one should recommend
| these methods of installation in 2025. I'm against closed
| computers but I'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.
| 01HNNWZ0MV43FF wrote:
| Maybe there will be a .deb one day
| mystifyingpoi wrote:
| That doesn't fix the core issue. You can put anything inside
| a .deb file, even preinstall script can send your
| ~/.aws/credentials to China. The core concern is getting a
| package that's verified by a volunteer human to not contain
| anything malicious, and then getting that package into Debian
| repository or equivalent.
| chasd00 wrote:
| can't you just do curl|more and then view what it's going to
| do? Then, once you're convinced, go back to curl|sh.
|
| /just guessing, haven't tried it
| threeducks wrote:
| A malicious server could detect whether the user is actually
| running "curl | sh" instead of just "curl" and only serve a
| malicious shell script when the code is executed blindly. See
| this thread for reference:
| https://news.ycombinator.com/item?id=17636032
| chasd00 wrote:
| well you still have to execute the shell script at some
| point. You could do curl > install.sh, open it up to
| inspect, and then run the install script which would still
| trigger the callback to the server mentioned in the link
| you posted. I guess it's really up to the user to decide
| what programs to run and not run.
| mystifyingpoi wrote:
| 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't.
| They provide a handy install script - don't like it? sure, grab
| the source and build it yourself. Oops, you don'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't that big of a stretch?
| WorldMaker wrote:
| For small project open source with a CLI audience, why bother
| with an install script at all and not just provide
| tarballs/ZIP files and assume that the CLI audience is smart
| enough to untarball/unzip it to somewhere on their PATH?
|
| Also, many of the "distribution" tools like brew, scoop,
| winget, and more are just "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". We're about at a minimum
| effort needed to generate a "distribution" point in software
| history, so seems interesting shell scripts to install things
| seem to have picked up instead.
| rieogoigr wrote:
| 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's the best installer
| you can do the rest of your code is probably trash.
| wtallis wrote:
| It's _not_ the best installer they can come up with. It 's
| just the most OS/distro-agnostic one-step installer they
| can come up with.
| jampekka wrote:
| Installing an out-of-distro deb/rpm/msi/dmg/etc package is just
| as unsafe as curl|sh. Or even unsafer, as packages tend to
| require root/admin.
| procaryote wrote:
| 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
| nikisweeting wrote:
| Security and auditability is not the core problem, it's
| versioning and uninstalling.
| https://docs.sweeting.me/s/against-curl-sh
| jampekka wrote:
| Uninstalling can be a problem.
|
| Versioning OTOH is often more problematic with distro
| package managers that can't support multiple versions of
| the same package.
|
| Also inability to do user install is a big problem with
| distro managers.
| 1718627440 wrote:
| That is still checked for its signature, the only thing you
| bypass is the automatic download over HTTP and dependency
| resolution by default.
| WorldMaker wrote:
| That iwr|iex example is especially egregious because it
| hardcodes the PowerShell <7.0 EXE name to include
| `-ExecutionPolicy Bypass`. So it'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.)
| rieogoigr wrote:
| 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.
| collinmanderson wrote:
| 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: https://github.com/astral-
| sh/uv/releases
| LeoPanthera wrote:
| 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: #!/usr/bin/env -S uv run --script
| # /// script # requires-python = ">=3.11" #
| dependencies = [ "modules", "here" ] # ///
|
| The script now works like a standalone executable, and uv will
| magically install and use the specified modules.
| d4mi3n wrote:
| If I were to put on my security hat, things like this give me
| shivers. It's one thing if you control the script and specified
| the dependencies. For any other use-case, you're trusting the
| script author to not install python dependencies that could be
| hiding all manner of defects or malicious intent.
|
| This isn't a knock against UV, but more a criticism of dynamic
| dependency resolution. I'd feel much better about this if UV
| had a way to whitelist specific dependencies/dependency
| versions.
| chatmasta wrote:
| 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.
| maccard wrote:
| 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
| p_l wrote:
| uv can still be redirected to private PyPi mirror, which
| should be mandatory from security and reliability perspective
| anyway.
| theamk wrote:
| Is there anything new that uv gives you here though?
|
| If you don't care about being ecosystem-compliant (and I am
| sure malware does not), it's only a few lines of Python to
| download the code and eval it.
| skinner927 wrote:
| 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.
| gcr wrote:
| Would you feel better with a script containing
| eval(requests.get("http://pypi.org/foo.py")) ?
|
| 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.
| kardos wrote:
| > uv will magically install and use the specified modules.
|
| As long as you have internet access, and whatever repository
| it's drawing from is online, and you may get different version
| of python each time, ...
| maccard wrote:
| 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.
| 85392_school wrote:
| You can constrain Python version:
| https://peps.python.org/pep-0723/#:~:text=requires-python
| dragonwriter wrote:
| I mean, if you use == constraints instead of >= 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't change dependency distribution, just
| streamlines use compared to manual setup of a venv per
| script.
| tclancy wrote:
| And electricity and running water and oh the inconvenience.
| How is this worse than getting a script file that expects you
| to install modules?
| moleperson wrote:
| 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.
| zahlman wrote:
| > Based on the man page it doesn't appear to be doing
| anything useful here
|
| The man page tells me: -S, --split-string=S
| process and split S into separate arguments; used to pass
| multi- ple arguments on shebang lines
|
| Without that, the system may try to treat the entirety of "uv
| run --script" as the program name, and fail to find it.
| Depending on your env implementation and/or your shell, this
| may not be needed.
|
| See also: https://unix.stackexchange.com/questions/361794
| moleperson wrote:
| Right, I didn't think about the shebang case being
| different. Thanks!
| Rogach wrote:
| Without -S, `uv run --script` would be treated as a binary
| name (including spaces) and you will get an error like "env:
| 'uv run --script': No such file or directory".
|
| -S causes the string to be split on spaces and so the
| arguments are passed correctly.
| gcr wrote:
| On these systems, wouldn't binfmt attempt to
| exec("/usr/bin/env -S uv run --script", "foo.py") and fail
| anyway for the same reason?
| zahlman wrote:
| As long as your `/usr/bin/env` supports `-S`, yes.
|
| It will install and use _distribution packages_ , to use PyPA's
| terminology; the term "module" 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
| (https://peps.python.org/pep-0723/) and pipx
| (https://pipx.pypa.io) also supports it.
| hugmynutus wrote:
| > As long as your
|
| linux 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 2008
|
| MacOS has basically always supported this.
|
| ---
|
| 1. Amusingly despite `POSIX_ME_HARDER` not being official a
| alrge swapt of core utils support it.
| https://www.gnu.org/prep/standards/html_node/Non_002dGNU-
| Sta...
| XorNot wrote:
| 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.
| miggol wrote:
| I wouldn't be surprised if astral's next product would be
| something like this. It'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.
| mr_mitm wrote:
| Zipapp comes close:
| https://docs.python.org/3/library/zipapp.html
| globular-toast wrote:
| You can get uv to generate this and add dependencies to it,
| rather than writing it yourself.
| pnt12 wrote:
| 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'm
| looking at you, yaml!)
| runningmike wrote:
| 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....
| maccard wrote:
| 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.
| LtWorf wrote:
| It's still annoying to fork and they will probably try to
| move it to their own pypi service so it won't be possible to
| do that.
| kyt wrote:
| 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's simultaneously trying to replace pip, pyenv,
| virtualenv, and ruff in one command.
|
| 2. You end up needing to use `uv pip` so it'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.
| defraudbah wrote:
| yeah, I've moved away from it too, but that's a great tool. A
| rush of rust tools is the best thing that happened to python in
| the decade
| leblancfg wrote:
| uv's pip interface is like dipping one toe in the bathtub. Take
| a minute and try on the full managed interface instead:
| https://docs.astral.sh/uv/concepts/projects/dependencies. Your
| commands then become:
|
| - uv add <package_name>
|
| - uv sync
|
| - uv run <command>
|
| Feels very ergonomic, I don't need to think much, and it's so
| much faster.
| daedrdev wrote:
| I mean I've had quite awful bugs from using pip pyenv and venv
| at the same time
| chatmasta wrote:
| What problems do you encounter using it with Docker?
| xmprt wrote:
| 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'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 "battle tested" tools.
| nicce wrote:
| Python versions and environments can be solved in more
| reliable abstraction level as well, e.g. if you are heavy Nix
| user.
| throwaway894345 wrote:
| On the other hand, Nix and Bazel and friends are a lot of
| pain. I'm sure the tradeoff makes sense in a lot of
| situations, but not needing to bring in Nix or Bazel just
| to manage dependencies is a pretty big boon. It would be
| great to see some of the all-in-one build tools become more
| usable though. Maybe one day it will seem insane that every
| language ecosystem has its own build tool because there's
| some all-in-one tool that is just as easy to use as
| `(car)go build`!
| eisbaw wrote:
| > Maybe one day it will seem insane that every language
| ecosystem has its own build tool because there's some
| all-in-one tool that is just as easy to use as `(car)go
| build`!
|
| Yep: Nix
| 331c8c71 wrote:
| Well Nix is the only sane way I know to manage fully
| reproducible envs that incorporate programs/scripts
| spanning multiple ecosystems. Very common situation in
| applied data analysis.
| jscheel wrote:
| oh man, don't even bother with bazel... hermetic python
| builds are such a mess.
| throwaway894345 wrote:
| Yeah, I agree. In particular it seems insane to me that
| virtualenv should have to exist. I can'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's the same sort of deal with pyenv--the Python version is
| itself a dependency of most libraries, so it's a little silly
| to have a dependency manager that only manages some
| dependencies.
| zahlman wrote:
| I, too, have ~20 years of Python experience.
|
| `virtualenv` is a heavy-duty third-party library that adds
| functionality to the standard library venv. Or rather, venv
| was created as a subset of virtualenv in Python 3.3, and
| the projects have diverged since.
|
| The standard library `venv` provides "obvious thing that a
| dependency manager does" functionality, so that every
| dependency manager has the opportunity to use it, and so
| that developers can also choose to work at a lower level.
| And the virtual-environment standard _needs to_ exist so
| that Python can _know about_ the pool of dependencies thus
| stored. Otherwise you would be forced to... depend on the
| dependency manager to start Python and tell it where its
| dependency pool is.
|
| Fundamentally, the _only_ things a venv needs are the
| `pyvenv.cfg` config file, the appropriate folder hierarchy,
| and some symlinks to Python (stub executables on Windows).
| _All_ it 's doing is providing a place for that "pool of
| dependencies" to exist, and providing configuration info so
| that Python can understand the dependency path at startup.
| The venvs created by the standard library module -- and by
| uv -- also provide "activation" scripts to manipulate some
| environment variables for ease of use; but these are
| completely unnecessary to making the system work.
|
| Fundamentally, tools like uv create the same kind of
| virtual environment that the standard library does --
| because there is only one kind. Uv doesn't bootstrap pip
| into its environments (since that's slow and would be
| pointless), but you can equally well disable that with the
| standard library: `python -m venv --without-pip`.
|
| > the Python version is itself a dependency of most
| libraries
|
| This is a strange way of thinking about it IMO. If you're
| trying to obtain Python libraries, it's normally because
| you already have Python, and want to obtain libraries that
| are compatible with the Python you already have, so that
| you can write Python code that uses the libraries and works
| under that Python.
|
| If you're trying to solve the problem of deploying an
| application to people who don't have Python (or to people
| who don't understand what Python is), you need another
| layer of wrapping anyway. You aren't going to get end users
| to install uv first.
| grebc wrote:
| I don't think people consider things from a first
| principles perspective these days.
|
| "...I can't see any valid use case for a machine-global
| pool of dependencies..." - Rhetorical question for OP but
| how do you run an operating system without having said
| operating systems dependencies available to everything
| else?
| knowitnone3 wrote:
| "other languages don't have 3 different tools for this." But
| other languages DO have 3 different tools so we should do
| that too!
| j2kun wrote:
| I think OP'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.
| collinmanderson wrote:
| > 1. It tries to do too many things. Please just do one thing
| and do it well. It'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?
|
| > 2. You end up needing to use `uv pip` so it's not even a full
| replacement for pip.
|
| What do end up needing to use `uv pip` for?
| eatonphil wrote:
| > 2. You end up needing to use `uv pip` so it's not even a full
| replacement for pip.
|
| Needing pip and virtualenvs was enough to make me realize uv
| wasn't what I was looking for. If I still need to manage
| virtualenvs and call pip I'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'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.
| ellg wrote:
| What are you needing to use `uv pip` for? I don'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
| ivell wrote:
| Pixi is an alternative that you may want to try.
| notatallshaw wrote:
| > I had been hoping someone would introduce the non-
| virtualenv package management solution that every single
| other language has where there'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't that exactly a pyproject.toml via the the uv
| add/sync/run interface? What is that missing that you need?
| eatonphil wrote:
| > pyproject.toml
|
| Ah ok I was missing this and this does sound like what I
| was expecting. Thank you!
| og_kalu wrote:
| In most cases, you don'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.
| dragonwriter wrote:
| > I had been hoping someone would introduce the non-
| virtualenv package management solution that every single
| other language has where there'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'm not sure how uv with
| pyproject.toml doesn't meet this description (yes, the venv
| is still _there_ , it is used exactly as you describe.)
| yoavm wrote:
| Really sounds like you're using it wrong, no? I completely
| forgot about virtualenvs, pip and requirements.txt since I
| start using UV.
| vindex10 wrote:
| I would also add UV_NO_SYNC as smth I had to learn. It comes in
| combination with uv pip
| wtallis wrote:
| What'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'm not sure what problem it solves.
| tpl wrote:
| What do you mean it doesn't play well with docker?
| nicoco wrote:
| uv pip is a full reimplementation of pip. Way faster, better
| caching, less disk usage. What'd not to like about it?
| brikym wrote:
| > 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't want to go shopping for things, or browse
| multiple docs. I just want it taken care of for me. I don't use
| uv so I don't know if the pieces fit together well but the
| kitset can work well and so can a la carte.
| a_bored_husky wrote:
| > 1. It tries to do too many things. Please just do one thing
| and do it well. It'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.
|
| > 2. You end up needing to use `uv pip` so it'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
|
| > 3. It does not play well with Docker.
|
| In what sense?
|
| > 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't need to touch them at all
| dragonwriter wrote:
| > It tries to do too many things. Please just do one thing and
| do it well. It's simultaneously trying to replace pip, pyenv,
| virtualenv, and ruff in one command.
|
| uv doesn't try to replace ruff.
|
| > You end up needing to use `uv pip` so it's not even a full
| replacement for pip.
|
| "uv pip" doesn'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.
|
| > It does not play well with Docker.
|
| How so?
| pityJuke wrote:
| There is an optional & experimental code formatting tool
| within uv (that just downloads riff), which is what OP may be
| referring to: https://pydevtools.com/blog/uv-format-code-
| formatting-comes-...
| j45 wrote:
| It's still one tool to orchestrate and run everything, which is
| preferable to many.
| TYPE_FASTER wrote:
| Yeah, I'm with you. I'm forcing myself to learn it because it
| looks like that's the way PyWorld is going. I don't dislike uv
| as much as poetry. But I guess I never really ran into issues
| using pyenv and pip. _shrug_ Maybe I wasn 't working on complex
| enough projects.
| groby_b wrote:
| > You end up needing to use `uv pip` so it's not even a full
| replacement for pip.
|
| No you don't. That's just a set of compatibility approaches for
| people who can't let go of pip/venv. Move to uv/PEP723, world's
| your oyster.
|
| > It does not play well with Docker.
|
| Huh? I use uv both during container build and container
| runtime, and it works just fine?
|
| > You end up needing to understand all of these new
| environmental variables
|
| Not encountered the need for any of these yet. Your comments on
| uv are so far out of line of all the uses I've seen, I'd love
| to hear what you're specifically doing that these become
| breaking points.
| dsnr wrote:
| 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.
| robertfw wrote:
| Slow doesn't really begin to do justice, I'd have to wait for
| >5 minutes for pipenv to finish figuring out our lock file.
| uv does it in less than a second.
| 9dev wrote:
| 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.
| scuff3d wrote:
| If your pyproject.toml is setup properly you shouldn't need to
| use `uv pip` at all.
|
| I'm using uv in two dozen containers with no issues at all. So
| not sure what you mean that it doesn't play well with Docker.
| tclancy wrote:
| So I have been doing Python for far too long and have all sort
| of tooling I'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's been glorious. I think the difference from your
| comment (and others in this chain) and my experience is that
| you're trying to make uv fit how you have done things. Jumping
| all the way in, I just . . . never needed virtualenvs. Don't
| really think about them once I sorted out a mistake I was
| making. uv init and you're pretty much there.
|
| >You end up needing to use `uv pip` so it's not even a full
| replacement for pip
|
| The only time I've used uv pip is on a project at work that
| isn't a uv-powered project. uv add should be doing what you
| need and it really fights you if you're trying to add something
| to global because it assumes that's an accident, which it
| probably is (but you can drop back to uv pip for that).
|
| >`UV_TOOL_BIN_DIR`, `UV_SYSTEM_PYTHON`, `UV_LINK_MODE`, etc.
|
| I've been using it for six months and didn't know those
| existed. I would suggest this is a symptom of trying to make it
| be what you'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.
| Narushia wrote:
| uv has played well with Docker in my experience, from dev
| containers to CI/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't already:
| https://docs.astral.sh/uv/guides/integration/docker/
| nomel wrote:
| 5. No concept of global/shell/local venv auto activation, so
| get used to typing "uv run", or manually recreating these
| concepts, with shell stuffs.
| l2silver wrote:
| It's funny, I feel like half the reason I use docker is for
| python projects.
| aerhardt wrote:
| I'm surprised by how much I prefer prepending "uv" to everything
| instead of activating environments - which is still naturally an
| option if that's what floats your boat.
|
| I also like how you can manage Python versions very easily with
| it. Everything feels very "batteries-included" and yet local to
| the project.
|
| I still haven't used it long enough to tell whether it avoids the
| inevitable bi-yearly "debug a Python environment day" but it's
| shown enough promise to adopt it as a standard in all my new
| projects.
| bobsomers wrote:
| Personally, I prefer prepending `uv` to my commands because
| they're more stateless that way. I don't need to remember which
| terminal my environment is sourced in, and when copying and
| pasting commands to people I don't need to worry about what
| state their terminal is it. It just works.
| zahlman wrote:
| > how much I prefer prepending "uv" to everything instead of
| activating environments
|
| You can also prepend the path to the virtual environment's bin/
| (or Scripts/ on Windows). Literally all that "activating an
| environment" 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's necessary to undo the changes (on my system that
| means defining a "deactivate" function; others may have a
| separate explicit script for that).
|
| I personally don't like the automatic detection of venvs, or
| the pressure to put them in a specific place relative to the
| project root.
|
| > I also like how you can manage Python versions very easily
| with it.
|
| I still don't understand why people value this so highly, but
| so it goes.
|
| > the inevitable bi-yearly "debug a Python environment day"
|
| If you're getting this because you have venvs based off the
| system Python and you upgrade the system Python, then no, uv
| can't do anything about that. Venvs aren'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.
| lelandbatey wrote:
| 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 "too confusing" and
| also don't know how they'd debug such a thing. Which I think
| is a shame since once you see that it's pretty simple it
| becomes a tool you can use everywhere. But given that people
| DON'T want to debug such, I can understand them liking a tool
| like uv.
|
| I do think automatic compiler/interpreter version management
| is a pretty killer feature though, that's really annoying
| otherwise typically afaict, mostly because to get non-system
| wide installs typically seems to require compiling yourself.
| biimugan wrote:
| Yup. I never even use activate, even though that's what you
| find in docs all over the place. Something about modifying my
| environment rubs me the wrong way. I just call
| ``./venv/bin/python driver.py`` (or ``./venv/bin/driver`` if
| you install it as a script) which is fairly self-evident,
| doesn't mess with your environment, and you can call into as
| many virtualenvs as you need to independently from one
| another.
|
| ``uv`` accomplishes the same thing, but it is another
| dependency you need to install. In some envs it's nice that
| you can do everything with the built-in Python tooling.
| 1718627440 wrote:
| And when you control the installation, you can install
| multiple python versions with `make altinstall` into the
| same prefix, so you don't even need to pass
| 'project/bin/python, you can just call 'python-project' or
| 'project.py' or however you like.
| zahlman wrote:
| Yep. (Although I installed into a hierarchy within /opt,
| and put symlinks to the binaries in /usr/local/bin.
| Annoyingly, I have to specify the paths to the actual
| executables when making venvs, so I have a little wrapper
| for that as well....)
| pnt12 wrote:
| If you have multiple python applications with different
| versions, it's nice to use the same version as deployed.
|
| At least major and minor, patch is rarely needed for python.
| j45 wrote:
| This isn't a comment just about Python.. but it should just
| work. There shouldn't be constant ceremony for getting and
| keeping environments running.
| oblio wrote:
| There are basically 0 other programming languages that use
| the "directory/shell integration activated virtual
| environment", outside of Python.
|
| How does the rest of the world manage to survive without
| venvs? Config files in the directory. Shocking, really :-)))
| roflyear wrote:
| what happens when you have two projects using different
| versions of node, etc? isn't that a massive headache?
|
| not that it's great to start with, but it does happen, no?
| oblio wrote:
| The rest of the world handles that through PATH/PATH
| equivalent.
|
| Either the package manager is invoked with a different
| PATH (one that contains the desired Node/Java/whatever
| version as a higher priority item than any other version
| on the system).
|
| Or the package manager itself has some way to figure that
| out through its config file.
|
| Or there is a package manager launch tool, just like
| pyenv or whatever, which does that for you.
|
| In practice it's not that a big of a deal, even for
| Maven, a tool created 21 years ago. As the average
| software dev you figure that stuff out a few weeks into
| using the tool, maybe you get burnt a few times early on
| for misconfiguring it and then you're on autopilot for
| the rest of your career.
|
| Wait till you hear about Java's CLASSPATH and the idea of
| having a SINGLE, UNIFIED package dependency repo on your
| system, with no need for per-project dependency repos
| (node_modules), symlinks, or all of that stupidity.
|
| CLASSPATH was introduced by Java in 1996, I think, and
| popularized for Java dependency management in 2004.
| 1718627440 wrote:
| Well, that is how Python does it as well, an venv is a
| script setting the PYTHONPATH.
| dragonwriter wrote:
| > The rest of the world handles that through PATH/PATH
| equivalent.
|
| Activating a venv is just setting a few environment
| variables, including PATH, and storing the old values so
| that you can put them back to deactivate the environment.
| whywhywhywhy wrote:
| The only word in the `source .venv/bin/activate` command
| that isn't a complete red flag that this was the wrong
| approach is probably bin. Everything else is so obviously
| wrong.
|
| source - why are we using an OS level command to activate a
| programming language's environment
|
| .venv - why is this hidden anyway, doesn't that just make
| it more confusing for people coming to the language
|
| activate - why is this the most generic name possible as if
| no other element in a system might need to be called the
| activate command over something as far down the chain as a
| python environment
|
| Feels dirty every time I've had to type it out and find it
| particularly annoying when Python is pushed so much as a
| good first language and I see people paid at a senior level
| not understand this command.
| zahlman wrote:
| > why are we using an OS level command to activate a
| programming language's environment
|
| Because "activating an environment" _means_ setting
| environment variables in the parent process (the shell
| that you use to run the command), which is otherwise
| impossible on Linux (see for example
| https://stackoverflow.com/questions/6943208).
|
| > why is this hidden anyway, doesn't that just make it
| more confusing for people coming to the language
|
| It doesn't have to be. You can call it anything you want,
| hidden or not, and you can put it anywhere in the
| filesystem. It so happens that many people adopted this
| convention because they liked having the venv in that
| location and hidden; and uv gives such venvs special
| handling (discovering and using them by default).
|
| > why is this the most generic name possible as if no
| other element in a system might need to be called the
| activate command over something as far down the chain as
| a python environment
|
| Because the entire point is that, when you need to
| activate the environment, the folder in question is _not_
| on the path (the purpose of the script is to put it on
| the path!).
|
| If activating virtual environments shadows e.g.
| /usr/bin/activate on your system (because the added path
| will be earlier in $PATH), you can still access that with
| a full absolute path; or you can forgo activation and do
| things like `.venv/bin/python -m foo`, `.venv/bin/my-
| program-wrapper`, etc.
|
| > Feels dirty every time I've had to type it out
|
| I use this: $ type activate-local
| activate-local is aliased to `source
| .local/.venv/bin/activate'
|
| Notice that, again, you don't have to put it at .venv . I
| use a .local folder to store notes that I don't want to
| publish in my repo nor mention in my project's
| .gitignore; it in turn has $ cat
| .local/.gitignore # Anything found in this
| subdirectory will be ignored by Git. # This is a
| convenient place to put unversioned files relevant to
| your # working copy, without leaving any trace in
| the commit history. *
|
| > and I see people paid at a senior level not understand
| this command.
|
| If you know anyone who's hiring....
| j45 wrote:
| Maybe it's just me, but it shouldn't be necessary to
| manage this and a few other things to get a python script
| working.
|
| uv has increased my usage of python for production
| purposes because it's maintainable by a larger group of
| people, and beginners can become competent that much
| quicker.
| zahlman wrote:
| > Config files in the directory.
|
| The problem is, that would require support from the Python
| runtime itself (so that `sys.path` can be properly
| configured at startup) and it would have to be done in a
| way that doesn't degrade the experience for people who
| _aren 't_ using a proper "project" setup.
|
| One of the big selling points of Python is that you can
| just create a .py file anywhere, willy-nilly, and execute
| the code with a Python interpreter, just as you would with
| e.g. a Bash script. And that you can incrementally build up
| from there, as you start out learning programming, to get a
| sense of importing files, and then creating meaningful
| "projects", and then thinking about packaging and
| distribution.
| 1718627440 wrote:
| There are path configuration files (*.pth) and you can
| configure sys.path in the script itself?
| zahlman wrote:
| Yes, and in principle you can install each package into a
| separate folder (see the `--target` option for pip) and
| configure sys.path manually like that.
|
| For .pth files to work, they have to be in a place where
| the standard library `site` module will look. You can add
| your own logic to `sitecustomize.py` and/or
| `usercustomize.py` but then you're really no better off
| vs. writing the sys.path manipulation logic.
|
| Many years ago, the virtual environment model was
| considered saner, for whatever reasons. (I've actually
| heard people cite performance considerations from having
| an overly long `sys.path`, but I really doubt that
| matters.) And it's stuck.
| 9dev wrote:
| And how is that different from any other interpreted
| language? Node and PHP handle this just fine, and they
| don't need a Rube Goldberg contraption to load
| dependencies from a relative directory or the systems
| library path. I really don't get why Python people act
| like that's some kind of wicked witchcraft?
| j45 wrote:
| The venv thing def stands out to me as being a bit of an
| outlier.
|
| If uv makes it invisible it is a step forward.
| 1718627440 wrote:
| It does, Python has essentially solved it for years.
| sirfz wrote:
| I use mise with uv to automatically activate a project's venv
| but prefixing is still useful sometimes since it would trigger
| a sync in case you forgot to do it.
| globular-toast wrote:
| 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.
| atonse wrote:
| These rust based tools really change the idea of what's possible
| (when you can get feedback in milliseconds). But I'm trying to
| figure out what Astral as a company does for revenue. I don'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'm not a full-time python developer.
| tabletcorry wrote:
| Take a look at their upcoming product Pyx to see where revenue
| can start to come in for paid/hosted services.
|
| https://astral.sh/pyx
| bruckie wrote:
| From "So how does Astral plan to make money? "
| (https://news.ycombinator.com/item?id=44358216):
|
| "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."
|
| There's also this interview with Charlie Marsh (Astral
| founder): https://timclicks.dev/podcast/supercharging-python-
| tooling-a... (specifically the "Building a commerical company
| with venture capital " section)
| throwway120385 wrote:
| That doesn't really seem like a way to avoid getting
| "Broadcommed." Vertically integrated tooling is kind of a
| commodity.
| LtWorf wrote:
| It doesn't seem to answer to anything.
| IshKebab wrote:
| Conda apparently makes a ton of money just by selling access to
| "more secure" packages, so maybe they'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.
| dark__paladin wrote:
| Genuinely trying to learn here - what's the major advantage of
| using uv over conda?
|
| (Transparently, I'm posting this before I've completed the
| article.)
| collinmanderson wrote:
| uv is unbelievably fast.
| zahlman wrote:
| The speed is quite believable. Reinstalling packages from a
| cache _should_ be extremely fast. Pip suffers from poor
| architecture.
| ethmarks wrote:
| 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're
| doing something with Node or R, uv won't work at all because
| it's only for Python.
|
| uv'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]: https://github.com/astral-sh/uv/blob/main/BENCHMARKS.md
| [2]: https://docs.astral.sh/uv/#scripts
| seabrookmx wrote:
| Can'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'm hoping astral's type checker is suitably good once released,
| because we're on mypy right now and it's a constant source of
| frustration (slow and buggy).
| kardos wrote:
| > because new poetry releases would stall trying to resolve
| dependencies.
|
| > uv is much faster than both of these tools
|
| conda 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?
| collinmanderson wrote:
| > 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.
| asaddhamani wrote:
| 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.
| tabletcorry wrote:
| 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't paying
| attention.
| theultdev wrote:
| well there's npm, pnpm, yarn, bun package managers
|
| not a python developer, so not sure it's equivalent as the npm
| registry is shared between all.
| collinmanderson wrote:
| > There's pip, virtualenv, pipx, uv, probably half a dozen
| others I'm missing...
|
| > Reminds me of that competing standards xkcd.
|
| Yes, for years I've sat on the sidelines avoiding the
| fragmented Poetry, ppyenv, pipenv, pipx, pip-tools/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.
| zahlman wrote:
| > 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.
| sdairs wrote:
| Everything from the astral team has been superb, I don't want to
| use Python without ruff & uv. Yet to try "ty", anyone used it?
| tabletcorry wrote:
| Ty is still under very active development, so it either works
| or very much doesn't. I run it occasionally to see if it works
| on my codebases, and while it is getting closer, it isn't quite
| there yet.
|
| Definitely lightyears faster than mypy though.
| collinmanderson wrote:
| I'm waiting for ty to get TypedDict checking.
| https://github.com/astral-sh/ty/issues/154
| sph wrote:
| There is something hilarious about using a project/package
| manager written in _another_ language.
| philipallstar wrote:
| Wait til you find out what CPython is written in.
| wiseowise wrote:
| Care to share with the group what's so hilarious?
| srameshc wrote:
| I am still learning and I have the same feeling as someone who
| don't consider myself good with python. At least I can keep my
| venv in control now is all I can feel with Uv approach.
| dec0dedab0de wrote:
| I don'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's a small price to pay for
| how fast it is.
| dekhn wrote:
| I hadn't paid any attention to rust before uv, but since starting
| to use uv, I'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't reproduce anything because just touching an env breaks the
| world.
| gostsamo wrote:
| 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.
| tempay wrote:
| There is also pixi (which uses uv for the python side of
| things) which feels like uv for conda.
| embe42 wrote:
| 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)
| th0ma5 wrote:
| 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.
| Difwif wrote:
| Pixi has also been such a breathe of fresh air for me. I
| think it's as big of a deal as UV (It uses UV under the hood
| for the pure python parts).
|
| It's still very immature but if you have a mixture of
| languages (C, C++, Python, Rust, etc.) I highly recommend
| checking it out.
| alfalfasprout wrote:
| Yep, pixi is game changing. Especially for AI/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.
| adastra22 wrote:
| I wish the Python ecosystem would just switch to Rust. Things
| are nice over here... please port your packages to crates.
| icar wrote:
| This seems to pretty much cover the same use cases as Mise.
| Is that true?
| kardos wrote:
| 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.
| PaulHoule wrote:
| I'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.
| kardos wrote:
| It seems they are using zstd now for .conda packages, eg,
| bzip is obsoleted, so that should be faster.
| whimsicalism wrote:
| 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?
| BoredPositron wrote:
| It's still used in edu and research. Haven't seen it in
| working environments in quite some time as well.
| dekhn wrote:
| At least on my cluster, few if any workloads are
| containerized. We also have an EKS where folks run
| containerized, but that's more inference and web serving,
| rather than training.
| jscyc wrote:
| Very common in education/research systems. Even the things
| which are containerised often have conda in them.
| savin-goyal wrote:
| the topic of managing large dependency chains for ML/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
|
| https://docs.metaflow.org/scaling/dependencies
| https://outerbounds.com/blog/containerize-with-fast-bakery
| jvanderbot wrote:
| 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's just
| becoming easier now with package managers.
| dekhn wrote:
| I've programmed all those languages before (learned C in '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.
| jvanderbot wrote:
| That is exactly how I feel about it. I've always loved C
| for it's simplicity and Rust felt like an accidental love
| letter.
| 1718627440 wrote:
| _NOW_? with package managers
| oofbey wrote:
| Have you found it easy to write rust modules with python
| interfaces? What tools do you recommend?
| warbaker wrote:
| Have you figured out a good way to manage CUDA dependencies
| with uv?
| zem wrote:
| I think ruff is the best thing to happen to the python ecosystem
| in a decade, it really sold the entire community on the
| difference fast native tooling could make.
| pixelpoet wrote:
| Wait until they fully embrace the benefits of strong typing :)
| psunavy03 wrote:
| I have one problem with uv as of now, and it's more of an
| annoyance. It doesn't seem to understand the concept of >= when
| it's trying to resolve a local wheel I built and use. If I have
| 6.4.1 published on GitLab and the pyproject says
| $WHEEL_NAME>=6.2.0, it still goes to look for 6.2.0 (which I
| deleted) and errors out.
| hglaser wrote:
| Am I the only one who feels like this is obviated by Docker?
|
| uv is a clear improvement over pip and venv, for sure.
|
| But I do everything in dev containers these days. Very few things
| get to install on my laptop itself outside a container. I've
| gotten so used to this that tools that uninstall/install packages
| on my box on the fly give me the heebie-jeebies.
| collinmanderson wrote:
| uv can be used to speed up building containers.
| czbond wrote:
| > I do everything in dev containers these days. Very few things
| get to install on my laptop itself outside a container.
|
| Yes, it was the NPM supply chain issues that really forced this
| one me. Now I install, fetch, build in an interactive Docker
| container
| zahlman wrote:
| Lots of people are doing things where they would prefer not to
| invoke the weight of an entire container.
| NumberCruncher wrote:
| > Am I the only one who feels like this is obviated by Docker?
|
| This whole discussion has the same vibes like digital
| photography 15 years ago. Back then some people spent more time
| on discussing the tech spec their cameras than takin photos.
| Now some people spend more time on discussing the pros and cons
| of different Python environment management solutions than
| building real things.
|
| The last time I had to touch one of my dockerized environments
| was when Miniconda and Miniforge were merged. I said the agent
| "fix the dockerfile", and the third attempt worked. Another
| time, one dependency was updated and I had to switch to Poetry.
| Once again, I said the agent "refactor the repository to
| Poetry" and it worked. Maybe because all my Python package
| versions are frozen and I only update them when they break or
| when I need the functionality of the new version.
|
| Whenever this topic pops up in real life, I always ask back
| what was the longest time they managed the same Python service
| in the cloud. In the most cases, the answer is never. The last
| time someone said one year. After a while this service was
| turned into two .py files.
|
| I don't know. Maybe I'm just too far away from FAANG level
| sorcery. Everything is a hammer if all you have to deal with
| are nails.
| dev_l1x_be wrote:
| And Rust is the best thing to happen to CS in a decade
| semiinfinitely wrote:
| I had a recent period in my programming career where I started to
| actually believe that the "worse is better" philosophy is true in
| practice. It was a dark period and thankfully the existence of
| tools like uv save me from that abyss.
| cyrialize wrote:
| I haven't tried uv yet, but I did use it's precursor - rye.
|
| I had to update some messy python code and I was looking for a
| tool that could handle python versions, package updates, etc.
| with the least amount of documentation needing be read and
| troubleshooting.
|
| Rye was that for me! Next time I write python I'm definitely
| going to use uv.
| sirfz wrote:
| Indeed rye is great and switching to uv is pretty straight
| forward. I still think rye's use of shims was pretty cool but
| probably uv's approach is more sane
| captain_coffee wrote:
| Yes, uv is probably the best thing to happen to the Py ecosystem
| in the last decade. That is mainly because the rest of the
| ecosystem is somewhere between garbage fire and mediocre at best.
| uv in itself is a great tool, I have no complaints about it
| whatsoever! But we have to remember just how bad the rest of
| things are and never forget that everything's still in a pretty
| bad state even after more than 3 ** DECADES ** of constant
| evolution.
| These335 wrote:
| Got a specific example in mind for garbage fire and mediocre?
| nothrowaways wrote:
| Does speed really matter during python installation?
| sunshowers wrote:
| Yes. Technical excellence is a virtue in and of itself.
| mwcampbell wrote:
| This! I'm tired of the constant calls to be as mediocre as we
| can get away with, in the name of getting things done faster
| and cheaper.
| collinmanderson wrote:
| It's fast enough that sometimes dependencies can be checked and
| resolved and installed at program runtime rather than it
| needing to be a separate step.
|
| You can go from no virtual environment, and just "uv run
| myfile.py" and it does everything that's needed, nearly
| instantly.
| maccard wrote:
| Speed matters everywhere. How much compute is spent on things
| that could easily be 100x faster than they are? Compare using
| VMware with pip to run a battery of unit tests with firecracker
| plus uv. It's orders of magnitude quicker, and avoids a whole
| suite of issues related to persistent state on the machine
| zahlman wrote:
| On my system, Pip takes noticeable time _just to start up_
| without ultimately doing anything of importance:
| $ time pip install ERROR: You must give at least one
| requirement to install (see "pip help install") real
| 0m0.356s user 0m0.322s sys 0m0.036s
|
| (Huh, that's a slight improvement from before; I guess pip 25.3
| is a bit better streamlined.)
| magdyks wrote:
| Huge fan of uv and ruff and starting to play around with ty. Hats
| of to astral!
| pjmlp wrote:
| Using Python on and off for OS scripting since version 1.6.
|
| It has always been enough to place installations in separate
| directories, and use the same bash scripts for environment
| variables configuration for all these years.
| j45 wrote:
| uv has definitely helped make python a first class citizen in
| more ways.
| isodev wrote:
| Or is it a corporate grab to gain more influence in the
| ecosystem? I like the idea, but for profit backing is out of the
| question. This lesson has been learned countless times.
| dcgudeman wrote:
| no, it's a python library, get a grip. Also "This lesson has
| been learned countless times"? No it hasn't, since when has a
| package manager developed by a for-profit company hurt the
| ecosystem?
| wiseowise wrote:
| Even if it was, that would be the best implementation of the
| strategy ever.
| collinmanderson wrote:
| They plan on making money by running private package
| registries, rather than making money on the client.
| https://astral.sh/pyx
| LtWorf wrote:
| What they say today and what will the board decide to do in 6
| months are 2 entirely separate things.
| tootie wrote:
| I've been using uv and am pleased that is about as useful as
| maven was the last time I used it 12 years ago. I'm not really
| sure why we still need venv.
| an_guy wrote:
| All these comments look like advertisement. "uv is better than
| python!!", "8/10 programmers recommend uv", "I was a terrible
| programmer before but uv changed my life!!", "uv is fast!!!"
| collinmanderson wrote:
| > All these comments look like advertisement. "uv is better
| than python!!", "8/10 programmers recommend uv", "I was a
| terrible programmer before but uv changed my life!!", "uv is
| fast!!!"
|
| Have you tried uv?
| an_guy wrote:
| Why would I? Does it offer something that standard python
| tools doesn't? Why uv over, lets say, conda?
| andy99 wrote:
| FWIW I asked the same question last time a uv thread was
| posted (two weeks ago) - got some legit answers, none that
| swayed me personally but I can see why people use it. Also
| lots of inexplicable love for it
| https://news.ycombinator.com/item?id=45574550
| dragonwriter wrote:
| > Does it offer something that standard python tools
| doesn't?
|
| Other than speed and consolidation, pip, pipx, hatch,
| virtualenv, and pyenv together roughly do the job (though
| pyenv itself isn't a standard python tool.)
|
| > Why uv over, lets say, conda?
|
| Support for Python standard packaging specifications and
| consequently also easier integration with other tools that
| leverage them, whether standard or third party.
| wiseowise wrote:
| Maybe open hundreds of threads praising uv to find what was
| answered thousand of times?
| andy99 wrote:
| First time reading one of these threads? It's a cult, and don't
| dare criticize it. I think the same thing used to be true with
| rust though nobody really talks about it much anymore.
|
| I don't think people would think twice about the legitimacy (if
| you want to call it that) of uv except for all the weird
| fawning over it that happens, as you noticed. It makes it seem
| more like a religion or something.
| taeric wrote:
| I still feel bitten by diving into poetry when starting some
| projects. Has the ecosystem fully moved on to uv, now? Do they
| have good influence on what python's main ecosystem is moving to?
| collinmanderson wrote:
| > Has the ecosystem fully moved on to uv, now?
|
| It's moving pretty quick.
|
| > Do they have good influence on what python's main ecosystem
| is moving to?
|
| Yes, they're an early adaptor/implementer of the recent
| pyproject.toml standards.
| taeric wrote:
| As someone that is fine on poetry for a few things, is there
| a good pitch deck on why I should change over?
| hardwaregeek wrote:
| I gotta say, I feel pretty vindicated after hearing for years how
| Python's tooling was just fine and you should just use virtualenv
| with pip and how JS must be worse, that when Python devs finally
| get a taste of npm/cargo/bundler in their ecosystem, they
| freaking love it. Because yes, npm has its issues but lock files
| and consistent installs are amazing
| WesolyKubeczek wrote:
| I somehow had quite enough problems going from bundler 1.13 to
| 1.16 to 2.x some years ago. I'm glad we have killed that
| codebase with fire.
| gigatexal wrote:
| the thing is I never had issues with virtual environments -- uv
| just allows me to easily determine what version of python that
| venv uses.
| j2kun wrote:
| you mean you can't just do `venv/bin/python --version`?
| shlomo_z wrote:
| he means "choose", not "check"
| gigatexal wrote:
| Yes sorry you're correct. It allows me to specify a
| version of Python.
| icedchai wrote:
| poetry gave us lock files and consistent installs for years. uv
| is much, much faster however.
| beeb wrote:
| I used poetry professionally for a couple of years and hit so
| many bugs, it was definitely not a smooth experience. Granted
| that was probably 3-4 years ago.
| icedchai wrote:
| I've occasionally run into performance issues and bugs with
| dependency resolution / updates. Not so much recently, but
| at a previous company we had a huge monorepo and I've seen
| it take forever.
| palm-tree wrote:
| I started using poetry abiut 4 years ago and definitely hit
| a lot of bugs around that time, but it seems to have
| improved considerably. That said, my company has largely
| moved to uv as it does seem easier to use (particularly for
| devs coming from other languages).
| teekert wrote:
| I always loved poetry but then I'd always run into that bug
| where you can't use repos with authentication. So I'd
| always go somewhere else eventually.
|
| Some time ago I found out it does work with authentication,
| but their "counter ascii animation" just covers it... bug
| has been open for years now...
| IshKebab wrote:
| The very first time I tried to use Poetry I ran into a bug
| where it couldn't resolve some simple dependencies.
|
| uv actually _works_.
| rcleveng wrote:
| and pip-compile before that.
|
| Agree that uv is way way way faster than any of that and
| really just a joy to use in the simplicity
| ShakataGaNai wrote:
| I have to agree that there were a lot of good options, but
| uv's speed is what sets it apart.
|
| Also the ability to have a single script with deps using TOML
| in the headers super eaisly.
|
| Also Also the ability to use a random python tool in
| effectively seconds with no faffing about.
| no_wizard wrote:
| There was pipenv before that too, which also had a lockfile.
|
| Funny how these things get forgotten to history. There's lots
| of prior art when it comes to replacing pip.
|
| edit: here's an HN thread about pipenv, where many say the
| same things about it as they are about UV and Poetry before
| https://news.ycombinator.com/item?id=16302570
| pydry wrote:
| >finally get a taste of npm
|
| good god no thank you.
|
| >cargo
|
| more like it.
| internetter wrote:
| cargo is better than npm, yes, but npm is better than pip (in
| my experience)
| DemocracyFTW2 wrote:
| As someone who moved from Python to NodeJS/npm ~10yrs ago I
| can fully support that statement. Dissatisfaction with
| Python's refusal to get its dependency/package-management
| act together and seeing how reasonably the task is being
| dealt with by `npm`--notably _with_ all its flaws--made me
| firmly stay with NodeJS. Actually virtualenv was for me
| _another reason to keep my fingers out of whatever they 're
| doing now over there in Python-land_, but maybe `uv` can
| change that.
| anp wrote:
| Might be worth noting that npm didn't have lock files for quite
| a long time, which is the era during which I formed my mental
| model of npm hell. The popularity of yarn (again importing
| bundled/cargo-isms) seems like maybe the main reason npm isn't
| as bad as it used to be.
| no_wizard wrote:
| npm has evolved, slowly, but evolved, thanks to yarn and
| pnpm.
|
| It even has some (I feel somewhat rudimentary) support for
| workspaces and isolated installs (what pnpm does)
| WatchDog wrote:
| Lock files are only needed because of semantic versioning.
|
| Maven worked fine without semantic versioning and lock files.
| kevin_thibedeau wrote:
| > you should just use virtualenv with pip
|
| This is the most insulting take in the ongoing ruination of
| Python. You used to be able to avoid virtualenvs and install
| scripts and dependencies directly runnable from any shell. Now
| you get endlessly chastised for trying to use Python as a
| general purpose utility. Debian was a bastion of sanity with
| the split between dist_packages and site_packages but that's
| ruined now too.
| whalesalad wrote:
| it's because so many essential system tools now rely on
| python, and if you install arbitrary code outside of a venv
| it can clobber the global namespace and break the core OS'
| guarantees.
|
| I do agree it is annoying, and what they need to do is just
| provide an automatic "userspace" virtualenv for anything a
| user installs themselves... but that is a pandoras box tbh.
| (Do you do it per user? How does the user become aware of
| this?)
| dragonwriter wrote:
| What they needed to do is allow side-by-side installs of
| different versions of the same distribution package and
| allow specifying or constraining versions at import time,
| then you wouldn't have the problem at all.
|
| But that's probably not practical to retrofit given the
| ecosystem as it is now.
| aunderscored wrote:
| pipx solves this perfectly.
| zahlman wrote:
| For "applications" (which are distributed on PyPI but
| include specified entry points for command-line use),
| yes. For development -- installing libraries that your
| own code will use -- you'll still generally need
| something else (although the restriction is really quite
| arbitrary).
| ElectricalUnion wrote:
| Unless all python dependencies you ever used were available
| in your distro (and then at that point, you're no longer
| using pip, you're using dpkg...), this never worked well.
| What solves this well is PEP 723 and tooling around it.
|
| With PEP 723 and confortable tooling (like uv), now you get
| scripts, that are "actually directly runnable", not just
| "fake directly runnable oops forgot to apt-get install
| something sorta runnable", and work reliably even when stuff
| around you is updated.
| whywhywhywhy wrote:
| > Python as a general purpose utility
|
| This ideology is what caused all the problems to begin with,
| the base python is built as if it's the only thing in the
| entire operating systems environment when it's entire
| packaging system is also built in a way that makes that
| impossible to do without manually having to juggle package
| conflicts/incompatibilities.
| zahlman wrote:
| > You used to be able to avoid virtualenvs and install
| scripts and dependencies directly runnable from any shell.
|
| This wasn't really the case; in principle anything you
| installed in the system Python environment, even "at user
| level", had the potential to pollute that environment and
| thus interfere with system tools written in Python. And if
| you did install it at system level, that became files within
| the environment your system package manager is managing, that
| it doesn't know how to deal with, because they didn't come
| from a system package.
|
| But it's worse now because of how many system tools are
| written in Python -- i.e., a mark of Python's success.
|
| Notably, these tools commonly include _the system package
| manager itself_. Since you mentioned Debian (actually this is
| Mint, but ya know): $ file `which apt`
| /usr/local/bin/apt: Python script, ASCII text executable
|
| > Now you get endlessly chastised for trying to use Python as
| a general purpose utility.
|
| No, you don't. Nothing prevents you from running scripts with
| the system Python that make use of system-provided libraries
| (including ones that you install later with the system
| package manager).
|
| If you need something that _isn 't packaged by your distro_,
| then of course you shouldn't expect your distro to be able to
| help with it, and of course you should expect to use an
| environment isolated from the distro's environment. In
| Python, virtual environments are _the_ method of isolation.
| All reasonable tooling uses them, _including uv_.
|
| > Debian was a bastion of sanity with the split between
| dist_packages and site_packages but that's ruined now too.
|
| It's not "ruined". If you choose to install the system
| package for pip and to use it with --break-system-packages,
| the consequences are on you, but you get the legacy behaviour
| back. And the system packages still put files separately in
| dist-packages. It's just that... doing this doesn't actually
| solve all the problems, fundamentally because of how the
| Python import system works.
| noirscape wrote:
| Nowadays pip also defaults to installing to the users home
| folder if you don't run it as root.
|
| Basically the only thing missing from pip install being a
| smooth experience is something like npx to cleanly run
| modules/binary files that were installed to that directory.
| It's still futzing with the PATH variable to run those
| scripts correctly.
| zahlman wrote:
| > Nowadays pip also defaults to installing to the users
| home folder if you don't run it as root.
|
| This could still cause problems if you run system tools
| as that user.
|
| I haven't checked (because I didn't install my distro's
| system package for pip, and because I use virtual
| environments properly) but I'm pretty sure that the same
| marker-file protection would apply to that folder
| (there's no folder there, on my system).
| 1718627440 wrote:
| This is very true! I was highly surprised when I installed
| Python from source and found out, that the entire problem is
| fixed since decades. You can have different Python versions
| in the same prefix just fine, you just need to pick a default
| one you install with `make install` and install all the
| others with `make altinstall`.
| chrisweekly wrote:
| Webdev since 1998 here. Tabling the python vs JS/etc to comment
| on npm per se. PNPM is better than npm in every way. Strongest
| possible recommendation to use it instead of npm; it's faster,
| more efficient, safer, and more deterministic. See
| https://pnpm.io/motivation
| Ant59 wrote:
| I've gone all-in on Bun for many of the same reasons.
| Blazingly fast installs too.
|
| https://bun.sh/
| ifwinterco wrote:
| I think at this point everyone on hacker news with even a
| passing interest in JS has heard of bun, it's promoted
| relentlessly
| trenchpilgrim wrote:
| I'm still meeting devs who haven't heard of it and get
| their minds blown when they replace npm in their
| projects. Every day is a chance to meet one of the lucky
| 10000: https://xkcd.com/1053/
| throw-the-towel wrote:
| Did you experience any compatibility problems with Bun?
| nullbyte wrote:
| I find pnpm annoying to type, that's why I don't use it
| bdangubic wrote:
| alias it to "p"
| DemocracyFTW2 wrote:
| IME after years of using pnpm exclusively having to type
| `pnpm install` instead of `npm install` is easily the
| single biggest drawback of replacing `npm` with `pnpm`, so
| yes.
|
| FWIW I use zsh with auto-auto-completion / auto-completion-
| as-you-type, so just hitting `p` on an empty command line
| will remember the most recent command starting with `p`
| (which was likely `pnpm`), and you can refine with further
| keystrokes and accept longer prefixes (like I always do
| that with `git add` to choose between typical ways to
| complete that statement). IMO people who don't use auto-
| completion are either people who have a magical ability to
| hammer text into their keyboards with the speed of light,
| or people who don't know about anything hence don't know
| about auto-completion, or terminally obsessive types who
| believe that only hand-crafting each line is worth while.
|
| I don't know which type of person you are but since typing
| `pnpm` instead of `npm` bothers you to the degree you
| refuse to use `pnpm`, I assume you must be of the second
| type. Did you know you can alias commands? Did you know
| that no matter your shell it's straightforward to write
| shell scripts that do nothing but replace obnoxious command
| invocations with shorter ones? If you're a type 3 person
| then of course god forbid, no true hacker worth their salt
| will want to spoil the purity of their artisanal command
| line incantations with unnatural ersatz-commands, got it.
| ASalazarMX wrote:
| Command alias? Even Windows can do them these days.
| tracker1 wrote:
| Deno is pretty sweet too... shell scripts that don't need a
| package.json or a node_modules directory for dependencies.
| globular-toast wrote:
| I've been using pip-tools for the best part of a decade. uv
| isn't the first time we got lock files. The main difference
| with uv is how it abstracts away the virtualenv and you run
| everything using `uv run` instead, like cargo. But you can
| still activate the virtualenv if you want. At that point the
| only difference is it's faster.
| caconym_ wrote:
| There is nothing I dread more within the general context of
| software development, _broadly_ , than trying to run other
| people's Python projects. Nothing. It's shocking that it has
| been so bad for so long.
| hardwaregeek wrote:
| Never underestimate cultural momentum I guess. NBA players
| shot long 2 pointers for decades before people realized 3 >
| 2. Doctors refused to wash their hands before doing
| procedures. There's so many things that seem obvious in
| retrospect but took a long time to become accepted
| brailsafe wrote:
| Most people in NA even spent thousands on cars and drove to
| get nearly anywhere until they discovered that trains
| exist... oh wait ;)
| trueismywork wrote:
| People in Europe spents years with people dying due to
| heat stress before they discovered ACs....
| PaulDavisThe1st wrote:
| This isn't really true. Heat stress deaths in Europe are
| comparitively rare, or were until urbanization and
| climate change became bigger factors.
| DarmokJalad1701 wrote:
| People in Europe spent years walking to the store
| everyday for food until they discovered that mechanical
| refrigeration exists...
| supportengineer wrote:
| Bad example. Walking to the store everyday for fresh food
| would be a _drastic_ improvement for most Americans.
| CharlieDigital wrote:
| Something I think that goes underappreciated: in many
| parts of the world, the food supply chain is shorter and
| the food is fresher to begin with. You're not meant to
| shop for 14 days at a time; you're meant to go more
| frequently and get what you need, fresh.
| tialaramex wrote:
| The refrigerator is a relatively modern invention.
| There's always been a refrigerator for me, but as a child
| my mother sometimes stayed with people who didn't own one
| and for _her_ mother they were a new invention many
| people didn 't have.
|
| Actually this idea of just buying things at "the store"
| is relatively new too. Historically people would make
| more things themselves, and more food would be purchased
| directly from farmers who had grown it.
| rustystump wrote:
| Wrong kind of cheek my friend
| IMTDb wrote:
| Usually when someone comes with that argument, I ask them
| to pick any week date in the past year and then I take a
| random item on my calendar on that day; I give them the
| time and address of where I need to be as well as the
| address of my home and I ask them how long it's going to
| take me and how much it's going to cost. That's usually
| enough to bring them down a notch from "train work" to
| "sometimes train work". (But they tend to forget very
| often, they need to be reminded regularly for some
| reason). Do you want to play that game with me to get
| your reality check in order ?
|
| Western Europe in a VERY dense city BTW.
| dpc050505 wrote:
| I'll happily play your game with a bicycle.
| moss_dog wrote:
| Are you arguing that trains are infeasible (due to cost
| or duration) for certain trips?
|
| I'm curious how this changes (in your mind) if "trains"
| can be expanded to "trains, buses, bicycle", or if you
| consider that to be a separate discussion.
| RobertoG wrote:
| pfff... "other people projects".. I was not even able to run
| my own projects until I started using Conda.
| lynndotpy wrote:
| I was into Python enough that I put it into my username but
| this is also my experience. I have had quasi-nightmares about
| just the bog of installing a Python project.
| Multicomp wrote:
| I agree with you wholeheartedly, besides not preferring
| dynamic programming languages, I would in the past have given
| python more of a look because of its low barrier to
| entry...but I have been repulsed by how horrific the
| development ux story has been and how incredibly painful it
| is to then distribute the code in a portable ish way.
|
| UV is making me give python a chance for the first time since
| 2015s renpy project I did for fun.
| acomjean wrote:
| You aren't kidding. Especially if it's some bioinformatics
| software that is just hanging out there on GitHub older than
| a year...
| throwaway2037 wrote:
| Do you think bioinformatics libs written in C++ do not have
| the same issues?
| tomaskafka wrote:
| So many times I have come onto a library or tool that would
| fix my problem, and then realized "oh crap, it's in Python, I
| don't want to spend few hours building a brittle environment
| for it only for that env to break next time I need to use it"
| - and went to look for a worse solution in better language.
| ghusto wrote:
| I really don't get this. I can count on no hands the number
| of times I've had problems simply going "pip install cool-
| thing-i-found".
|
| Sure, this is just my experience, but I use Python a lot
| and use a lot of tools written in Python.
| dragonwriter wrote:
| Recently (like for several years), with most packages
| providing wheels for most platforms, it tends to be less
| of a problem of things actually working, except for
| dependencies where the platform specifiers used by Python
| are insufficient to select the right build of the
| dependency, like PyTorch.
| wongarsu wrote:
| If you can install it with `pip install program-name`
| it's usually packaged well enough to just work. But if
| it's a random github repository with a requirements.txt
| with no or very few version numbers chances are that just
| running `pip install -r requirements.txt` will lead you
| down an hour+ rabbit hole of downgrading both your venv's
| python version and various packages until you get a
| combination that is close enough to the author`s venv to
| actually work
|
| Usually happens to me when I find code for some research
| paper. Even something that's just three months old can be
| a real pain to get running
| IgorPartola wrote:
| Seconded. Python, even with virtualenv stuff, has never
| been bad. There have been a few things that have been
| annoying especially when you need system libraries (e.g.
| libav for PyAV to work, etc.), but you have the same
| issue with every other ecosystem unless the packages come
| with all batteries included.
|
| To be fair to the GP comment, this is how I feel about
| Ruby software. I am not nearly as practiced at installing
| and upgrading in that ecosystem so if there was a way to
| install tools in a way that lets me easily and completely
| blow them away, I would be happier to use them.
| virtue3 wrote:
| I still have nightmares about nokogiri gem installs from
| back in the day :/
| lacker wrote:
| The only thing I dreaded more was trying to run other
| people's C++ projects.
| the__alchemist wrote:
| Same! And Python was my first, and is currently my second-
| highest-skill language. If someone's software's installation
| involves Python, I move on without trying. It used to be that
| it would require a Python 2 interpreter.
|
| Honorable mention: Compiling someone else's C code. Come on;
| C compiles to a binary; don't make the user compile.
| TheCondor wrote:
| How about shipping one? Like even just shipping some tools to
| internal users is a pain
| luckydata wrote:
| The python community was in profound denial for a very long
| time.
| LtWorf wrote:
| Just stick to what's in your linux distribution and you've
| got no problems.
| esseph wrote:
| No need, run python as a container. No need to mix what's
| installed on the hostOS.
|
| https://hub.docker.com/_/python
| mk89 wrote:
| I have used
|
| pip freeze > requirements.txt
|
| pip install -r requirements.txt
|
| Way before "official" lockfile existed.
|
| Your requirements.txt becomes a lockfile, as long as you accept
| to not use ranges.
|
| Having this in a single tool etc why not, but I don't
| understand this hype, when it was basically already there.
| icedchai wrote:
| That works for simple cases. Now, update a transitive
| dependency used by more than one dependency. You might get
| lucky and it'll just work.
| bdangubic wrote:
| it won't work of course, no one is that lucky :)
| mk89 wrote:
| Not sure how uv helps here, because I am not very familiar
| with it.
|
| With pip you update a dependency, it won't work if it's not
| compatible, it'll work if they are. Not sure where the
| issue is?
| pridkett wrote:
| Simple for simple cases - but you update a dependency and
| that updates a dependency that has a window range of
| dependencies because one version had a security issue
| which causes you to downgrade three other packages.
|
| It can get complicated. The resolver in uv is part of its
| magic.
|
| https://docs.astral.sh/uv/reference/internals/resolver/
| noosphr wrote:
| JavaScript has truly rotted the brains of software
| developers.
|
| You include the security patch of whatever your
| dependencies are into your local vetted pypi repository.
| You control what you consider liabilities and you don't
| get shocked by breakages in what should be minor
| versions.
|
| Of course you have to be able to develop software and not
| just snap Lego's together to manage a setup like that.
| Which is why uv is so popular.
| Capricorn2481 wrote:
| You can make it a language flame war, but the Python
| ecosystem has had no problem making this bed for
| themselves. That's why people are complaining about
| running other people's projects, not setting up their
| own.
|
| Sensible defaults would completely sidestep this, that's
| the popularity of uv. Or you can be an ass to people
| online to feel superior, which I'm sure really helps.
| 9dev wrote:
| Im wondering if people like you are getting paid to vet
| other people's libraries? Because with every modern
| project I have ever seen, you can't do too much the rest
| of the day with the amount of library updates you have to
| be vetting.
| Capricorn2481 wrote:
| He's a consultant. Making everyone else sound incompetent
| is part of the gig.
| throw-the-towel wrote:
| You're implying that I have to run a local Pypi just to
| update some dependencies for a project? When other
| languages somehow manage without that? No way I'm doing
| that.
| kstrauser wrote:
| > it won't work if it's not compatible
|
| This is very new behavior in pip. Not so long ago,
| imagine this:
|
| You `pip install foo` which depends on `bar==1.0`. It
| installs both of those packages. Now you install `pip
| install baz` which depends on `bar==2.0`. It installs
| baz, and updates bar to 2.0. Better hope foo's compatible
| with the newer version!
|
| I think pip only changed in the last year or two to
| resolve conflicts, or die noisily explaining why it
| couldn't be done.
| morkalork wrote:
| I remember advocating for running nightly tests on every
| project/service I worked on because inevitably one night
| one of the transitive dependencies would update and shit
| would break. And at least with the nightly test it forced
| it to break early vs when you needed to do something else
| like an emergency bug fix and ran into then..
| auraham wrote:
| Can you elaborate on this? How is npm/cargo/etc better than
| pip on this regard?
|
| As far as I know, files like requirements.txt,
| package.json, cargo.toml are intended to be used as a
| snapshot of the dependencies in your project.
|
| In case you need to update dependency A that also affects
| dependency B and C, I am not sure how one tool is better
| than other.
| jeremyjh wrote:
| They will resolve a version that works for all
| dependencies if it exists.
| ifwinterco wrote:
| It is indeed fairly simple to implement it, which is why it's
| so weird that it's never been implemented at a language level
| rtpg wrote:
| As a "pip is mostly fine" person, we would direct the result
| to a new lock file, so you could still have your direct does
| and then pin transitives and update
|
| Pips solver could still cause problems in general on changes.
|
| UV having a better solver is nice. Being fast is also nice.
| Mainly tho it feeling like it is a tool that is maintained
| and can be improved upon without ripping one's hair out is a
| godsend.
| epage wrote:
| Good luck if you need cross-platform `requirements.txt`
| files.
| mk89 wrote:
| This is a good use case. Not sure how this is typically
| solved, I guess "requirements-os-version.txt"? A bit
| redundant and repetitive.
|
| I would probably use something like this:
| https://stackoverflow.com/questions/17803829/how-to-
| customiz...
| trenchpilgrim wrote:
| But then you have to m x n x o it for different
| combinations of Python version, OS, CPU architecture, GPU
| make/model... uv will solve it for you in milliseconds.
| freehorse wrote:
| How does uv solve that? Like, if you use dependencies that
| do not cross platforms very well?
| mirashii wrote:
| uv finds a dependency resolution that works for all
| platforms by default, and can do things like fork the
| resolution and choose different versions based on
| platform or python version requirements.
| 2wrist wrote:
| It is also manages the runtime, so you can pin a specific
| runtime to a project. It is very useful and worth
| investigating.
| mk89 wrote:
| I think it's a great modern tool, don't get me wrong.
|
| But the main reason shouldn't be the "lockfile". I was
| replying to the parent comment mainly for that particular
| thing.
| ghusto wrote:
| I've never even understood the virtual env dogma. I can see
| how version conflicts _could_ happen, but they never have.
| Admittedly, I'm surprised I never have issues installing
| globally, especially since others keep telling me what a
| terrible idea it is and how they had nightmare-scenario-X
| happen to them.
| digisign wrote:
| I only ever had it a problem with large, poorly maintained
| projects from work. You know the kind that have two web
| frameworks required in the same project, and two orms, etc.
| ;-) That one I definitely put into a venv. But my stuff,
| no.
| not_kurt_godel wrote:
| And then you're sunk the moment anyone else needs to run
| your code, or even if you just need to run your own code
| on another machine.
| tecoholic wrote:
| How do you work with multiple projects with different
| versions of the same dependencies? If you are using the
| "system python" for everything?
| electroglyph wrote:
| it's very common for different projects to have different
| requirements, especially for fast moving libraries like
| transformers. if you rarely run python stuff it might not
| be a big deal, but i'd rather not have to reinstall stuff
| (especially big stuff like pytorch builds) every time i
| switch projects.
| tecoholic wrote:
| I am on the same boat. I like uv for its speed and other
| niceties it brings and being a single tool to manage
| different things. But lockfile is not that big a deal. I
| never got Poetry as well. Tried it in a project once and the
| lockfile was a pain with the merges. I didn't spend much
| time, so maybe I didn't understand the tool and workflow or
| whatever, but pip and pip-tools were just fine working with
| requirements.txt.
| pnt12 wrote:
| This is way less than what uv and other package managers do:
|
| - dev dependencies (or other groups) - distinguishing between
| direct and indirect dependencies (useful if you want to cut
| some fat from a project) - dependencies with optional extra
| dependencies (if you remove the main, it will delete the
| orphans when relevant)
|
| It's not unachievable with pip and virtualenvs, but verbose
| and prone to human error.
|
| Like C: if you're careful enough, it can be memory safe. But
| teams would rather rely on memory safe languages.
| avidphantasm wrote:
| I don't get the hype either. Every time I've tried to use
| tools like pyenv or pipenv they fall down when I try to
| install anything that doesn't provide wheels (GDAL), so I
| give up and stick to pip and virtualenv. Does uv let me
| install GDAL without hassle?
| kstrauser wrote:
| Pyenv's a different animal. It's meant for installing
| multiple Python versions at once so that you're not stuck
| with whatever dog your base OS happens to ship.
|
| Pipenv tried to be what uv is, but it never did seem to
| work right, and it had too many weird corner cases ("why is
| it suddenly taking 3 hours to install packages? why it is
| literally impossible to get it to upgrade one single
| dependency and not all the others?") to ever be a
| contender.
| selcuka wrote:
| The canonical way to do this with pip was using Constraints
| Files [1]. When you pollute your main requirements.txt it
| gets harder to see which package is an actual dependency of
| your project, and which ones are just sub-dependencies.
| Constraint files also let you not install a package if it's
| no longer a sub-dependency.
|
| That being said, the uv experience is much nicer (also
| insanely fast).
|
| [1] https://pip.pypa.io/en/stable/user_guide/#constraints-
| files
| NaomiLehman wrote:
| conda was great to me
| odyssey7 wrote:
| Python might have been better at this but the community was
| struggling with the 2 vs 3 rift for years. Maybe new tooling
| will change it, but my personal opinion is that python does not
| scale very well beyond a homework assignment. That is its sweet
| spot: student-sized projects.
| Spivak wrote:
| But you _are_ just using virtualenv with pip. It doesn 't
| change any of the moving pieces except that uv is virtualenv
| aware and will set up / use them transparently.
|
| You've been able to have the exact same setup forever with
| pyenv and pyenv-virtualenv except with these nothing ever has
| to be prefixed. Look, uv is amazing and I would recommend it
| over everything else but Python devs have had this flow
| forever.
| dragonwriter wrote:
| > But you are just using virtualenv with pip.
|
| No, you aren't.
|
| > It doesn't change any of the moving pieces
|
| It literally does, though iyt maintains a mostly-parallel
| low-level interface, the implementation is replaced with
| improved (in speed, in dependency solving, and in other
| areas.) You are using virtual environments (but not
| venv/virtualenv) and the same _sources_ that pip uses (but
| not pip).
|
| > You've been able to have the exact same setup forever with
| pyenv and pyenv-virtualenv except with these nothing ever has
| to be prefixed.
|
| Yes, you can do a subset of what uv does with those without
| prefixes, and if you add pipx and hatch (though with hatch
| you'll be prefixing for much the same reason as in uv) you'll
| get closer to uv's functionality.
|
| > Look, uv is amazing and I would recommend it over
| everything else but Python devs have had this flow forever.
|
| If you ignore the parts of the flow built around modern
| Python packaging standards like pyproject.toml, sure, pieces
| of the flow have been around and supported by the right
| constellation of other standard and nonstandard tools for a
| while.
| ForHackernews wrote:
| To be fair, Poetry has done everything uv does for about a
| decade. uv is much faster, which is great, but lock files,
| integrated venv management, etc.
| silverwind wrote:
| Yep, coming from poetry, uv is a pure speed increase with the
| same feature set.
| mbac32768 wrote:
| > that when Python devs finally get a taste of
| npm/cargo/bundler in their ecosystem, they freaking love it.
| Because yes, npm has its issues but lock files and consistent
| installs are amazing
|
| I think it's more like Rust devs using Python and thinking what
| the fuck why isn't this more like rustup+cargo?
| jrochkind1 wrote:
| Yeah, python's tooling for dependency management was definitely
| not just fine, it was a disaster.
|
| Coming from ruby. However, I think uv has actually now
| surpassed bundler and the ruby standard toolset for these
| things. Definitely surpassed npm, which is also not fine.
| Couldn't speak for cargo.
| devlovstad wrote:
| uv has made working with different python versions and
| environments much, much nicer for me. Most of my colleagues in
| computational genomics use conda, but I've yet to encounter a
| scenario where I've been unable to just use uv instead.
| bfkwlfkjf wrote:
| The best thing about uv is it's not conda.
|
| Pip is also not conda, but uv is way faster than pip.
| samgranieri wrote:
| I'm not a pythonista, and the most recent time I've been playing
| with python has been using octodns. origninally I was using a pip
| setup, and honestly wow UV was so much faster.
|
| I'm very happy the python community has better tooling.
| hirako2000 wrote:
| A problem remain in that many and still more of the popular
| repositories don't use uv to manage their dependencies.
|
| So you are back having to use conda and the rest. Now, you have
| yet another package manager to handle.
|
| I wouldn't be harsh to engineers at astral who developed amazing
| tooling, but the issue with the python ecosystem isn't lack of
| tooling, it is the proliferation and fragmentation. To solve
| dependency management fully would be to incorporate other package
| descriptors, or convert them.
|
| Rsbuild, another rust library, for the node ecosystem did just
| that. For building and bundling. They came up with rspack, which
| has large compatibility with the webpack config.
|
| You find a webpack repo? Just add rsbuild, rspack, and you are
| pretty much ready to go, without the slow (node native) webpack.
| oblio wrote:
| Don't they publish to PyPi? What do you care what they use
| behind the scenes?
| hirako2000 wrote:
| It isn't what they use under the scene.
|
| I refered to the interfaces of other packaging tools. I use
| uv and it's excellent on its own.
|
| You get a repo, it's using playwright, what do you do now ?
| You install all the dependencies found in the dependency
| descriptor then sync to create a uv descriptor. or you
| compose a descriptor that uv understands.
|
| It's repetitive, rather systematic so it could be automated.
| I should volunteer for a PR but my point is introducing yet
| another tool to an ecosystem suffering a proliferation of
| build and deps management tooling expands the issue. It would
| have been helpful from the get go to support existing and
| prolific formats.
|
| pnpm understands package.json It didn't reinvent the wheel be
| cause we have millions of wheels out there. It created its
| own pnpm lock file, but that's files a user isn't meant to
| touch so it goes seamlessly to transition from npm to pnpm.
| Almost the same when migrating from webpack to rsbuild.
| zahlman wrote:
| When packages require conda, that has _nothing to do with_ them
| "not using uv to manage their dependencies".
|
| Conda solves a completely orthogonal set of problems, and is
| increasingly unnecessary. You can `pip install scipy` for
| example, and have been able to for a while.
| pama wrote:
| I love uv. But the post starts with a simple install using a
| oneliner curl piping to sh, which is such a big attack surface
| area... I would much rather have a much longer one liner that
| increases safety.
| oblio wrote:
| Isn't uv like... a Rust binary? If that sh has any sense it
| just copies the binary and adds it to PATH.
| rieogoigr wrote:
| but since you are curling a web URL straight to sh you will
| never know. which is the problem.
| dboon wrote:
| If you look at the script, this is indeed more or less what
| happens. Except the folks over there are very clever about
| ergonomics, so the script is quite long so it can detect your
| architecture, OS, and even libc to give you an appropriate
| binary. There's a tool that they use (which they wrote) which
| generates such install scripts for you
|
| It's really excellent stuff
| hirako2000 wrote:
| It seems to be a trend in the rust community. I guess because
| rustup is suggested to be installed that way.
|
| But you don't have to. Brew and other package managers hold uv
| in their registries.
| mhogers wrote:
| Seeing a `pip install -r requirements.txt` in a very recently
| created python project is almost a red flag now...
| nomel wrote:
| requirements.txt allows pip arguments to be included, so can be
| doing much more than just listing package names.
|
| For example, installing on an air gapped system, where uv
| barely has support.
| FattiMei wrote:
| But what was wrong with pip, venv and pyproject.toml in the first
| place? I just keep a system installation of python for my
| personal things and an environment for every project I'm working
| on. I'd get suspicious if a developer is picky about python
| versions or library versions like what crazy programs are you
| writing?
| wrs wrote:
| The pytorch ecosystem, for one, is notorious for very specific
| version dependencies between libraries.
| jvanderbot wrote:
| What was wrong was that you needed to do that.
|
| How many commands are required to build up a locally consistent
| workspace?
|
| Modern package managers do that for you.
| oblio wrote:
| How do pip and venv integrate with pyproject.toml? At least pip
| doesn't even use it.
| zahlman wrote:
| As of half a year ago with pip 25.1, it can install from
| "dependency groups" listed in pyproject.toml:
| https://ichard26.github.io/blog/2025/04/whats-new-in-
| pip-25....
|
| Pip also generates PEP 751 lockfiles, and installing from
| those is on the roadmap still
| (https://github.com/pypa/pip/issues/13334).
|
| venv is lower-level tooling. Literally all it does is create
| a virtual environment -- _the same kind_ that uv creates and
| manages. There 's nothing to "integrate".
| johnfn wrote:
| As mostly a Python outsider, in the infrequent times that I do
| use python package management, uv just works. When I use pip
| I'd get all sorts of obscure error messages that I'd have to go
| track down, probably because I got some obscure environment
| detail wrong. With uv I never run into that nonsense.
| the8472 wrote:
| What's wrong? Having modify the shell environment, no lockfile,
| slow download/installation, lack of a standard dependency dir,
| ...
|
| > I'd get suspicious if a developer is picky about python
| versions or library versions
|
| Certain library versions only support certain python versions.
| And they also break API. So moving up/down the python versions
| also means moving library versions which means stuff no longer
| works.
| zahlman wrote:
| You don't have to modify the environment (this is provided as
| an _option_ for convenience). The alternatives are to use
| higher-level management like uv does, or to specify the path
| to executables in the virtual environment directly. But uv
| works by creating virtual environments that are essentially
| the same as what you get with `python -m venv --without-pip`
| (although they reimplemented the venv creation logic).
|
| Pip can install from dependency groups in a pyproject.toml
| file, and can write PEP 751 lockfiles, and work is under way
| to allow it to install from those lockfiles as well.
|
| I don't know what you mean about a "standard dependency dir".
| When you make a venv yourself, you can call it what you want,
| and put it where you want. If you want to put it in a
| "standard" place, you can trivially make a shell alias to do
| so. (You can also trivially make a shell alias for "activate
| the venv at a hard-coded relative path", and use that from
| your project root.)
|
| Yes, pip installation is needlessly slow for a variety of
| reasons (that mostly do _not_ have to do with being
| implemented in Python rather than Rust). Resolving
| dependencies is also slow (and Rust may be more relevant
| here; I haven 't done detailed testing). But your _download_
| speed is still going to be primarily limited by your internet
| connection to PyPI.
| the8472 wrote:
| I'm confused by this reply.
|
| > The alternatives are to use higher-level management like
| uv does,
|
| The question was specifically what's wrong with pip, venv
| and pyproject toml, i.e. what issues uv is trying to
| address. Well of course the thing trying to address the
| problem addresses the problem....
|
| > I don't know what you mean about a "standard dependency
| dir".
|
| like node's node_modules, or cargo's ~/.cargo/registry. You
| shouldn't have to manually create and manage that.
| installing/building should just create it. Which is what uv
| does and pip doesn't.
|
| > the same as what you get with `python -m venv --without-
| pip`
|
| The thing that should be automatic. And even if it is not
| it should at least be less arcane. An important command
| like that should have been streamlined long ago. One of the
| many improvements uv brings to the table.
|
| > and work is under way to allow it to install from those
| lockfiles as well.
|
| Yeah well, the lack up until now is one of those "what is
| wrong" things.
|
| > But your download speed is still going to be primarily
| limited by your internet connection to PyPI.
|
| Downloading lots of small packages dependencies serially
| leaves a lot of performance on the table due to latency and
| non-instantaneous response from congestion controllers.
| Downloading and installing concurrently reduces walltime
| further.
| zahlman wrote:
| > Well of course the thing trying to address the problem
| addresses the problem....
|
| The point is that it is _a_ thing trying to address the
| "problem", and that not everyone considers it a problem.
|
| > Which is what uv does and pip doesn't.
|
| The point is that you might want to install something
| _not_ for use in a "project", and that you might want to
| explicitly hand-craft the full contents of the
| environment. Pip is fundamentally a lower-level tool than
| uv.
|
| > The thing that should be automatic.
|
| Bootstrapping pip is the default so that people who have
| barely learned what Python is don't ask where pip is, or
| why pip isn't installing into the (right) virtual
| environment.
|
| Yes, there are lots of flaws in pip. The problem is not
| virtual environments. Uv uses the same virtual
| environments. Neither is the problem "being a low-level
| tool that directly installs packages and their
| dependencies". I actively want to have that tool, and
| actively don't want a tool that tries to take over my
| entire project workflow.
| zahlman wrote:
| Design-wise, nothing, IMO. But I don't fault people who prefer
| the uv workflow, either. Chacun a son gout.
|
| Implementation-wise, there's nothing wrong in my view with
| venv. Or rather, everything is compelled to use virtual
| environments, including uv, and venv is just a simple tool for
| doing so manually. Pip, on the other hand, is slow and bulky
| due to poor architecture, a problem made worse by the
| expectation (you can work around it, but it requires additional
| understanding and setup, and isn't a perfect solution) of re-
| installing it into each virtual environment.
|
| (The standard library venv defaults to such installation; you
| can disable this, but then you have to have a global pip set
| up, and you have to direct it to install into the necessary
| environment. One sneaky way to do this is to install Pipx, and
| then set up some script wrappers that use Pipx's vendored copy
| of pip. I describe my techniques for this in
| https://zahlman.github.io/posts/2025/01/07/python-
| packaging-....)
|
| Edit: by "design" above I meant the broad strokes of how you
| use pip, installing single packages with their transitive
| dependencies etc. There's a lot I would change about the CLI
| syntax, and other design issues like that.
| wrs wrote:
| Every time I see one of these comment threads it seems like uv
| desperately needs a better home page that doesn't start with a
| long list of technical stuff. It's really simple to use, in fact
| so simple that it confuses people!
|
| The home page should be a simplified version of this page buried
| way down in the docs: https://docs.astral.sh/uv/guides/projects/
| CalChris wrote:
| Mojo?
| zahlman wrote:
| As far as I can tell, Mojo doesn't have very broad adoption. It
| also isn't actually Python, it just looks like it.
| ModernMech wrote:
| Mojo stopped saying out loud they are trying to be a Python
| superset. Maybe they can do it one day but they're keeping that
| on the DL now because it's a really big ask.
| kristopolous wrote:
| Hype is dangerous
| docsaintly wrote:
| Python venv's is the #1 reason I've avoided working with it more.
| It used to be #2 behind strong typing, but now that Linux OSes'
| take up the default python install and block it from being used
| for quick scripts, it jumped to #1.
|
| I've always wondered why Linux OSes that rely on python scripts
| don't make their own default venv and instead clobber the user's
| default python environment...
| mosselman wrote:
| uv is great. I am a Ruby developer and I always loathed having to
| work with Python libraries because of how bad the tooling was. It
| was too complex to learn for the one-off times that I needed it
| and nothing worked properly.
|
| Now with uv everything just works and I can play around easily
| with all the great Python projects that exist.
| j2kun wrote:
| This article appears to be NOT about someone who discovered uv
| after using venv/pip, but rather an article about someone who
| discovered uv after not using virtual environments at all, and is
| mostly excited about the cleanliness of virtual environments.
| collinmanderson wrote:
| The article shows some advantages compared to plain virtual
| environments:
|
| In principle, you can 'activate' this new virtual environment
| like any typical virtual environment that you may have seen in
| other tools, but the most 'uv-onic' way to use uv is simply to
| prepend any command with uv run. This command automatically
| picks up the correct virtual environment for you and runs your
| command with it. For instance, to run a script -- instead of
| source .venv/bin/activate python myscript.py
|
| you can just do uv run myscript.py
| zahlman wrote:
| > The article shows some advantages compared to plain virtual
| environments
|
| No; they _are_ plain virtual environments. There is no
| special kind of virtual environment. Uv simply offers its own
| command structure for managing those environments. In
| particular, `uv run` just ensures a venv in a specific
| location, then uses it.
|
| There is no requirement to activate virtual environments in
| order to use them (unless you have some other tooling that
| specifically depends on the environment variables being set).
| You can, similarly, "just do"
| .venv/bin/python myscript.py
|
| without uv installed.
|
| > This command automatically picks up the correct virtual
| environment for you
|
| Some people dislike such magic, especially since it involves
| uv having an opinion about where the virtual environment is
| located.
| mannicken wrote:
| God yes. I got dragged into the uv when I started using copyparty
| and I am a fanatical admirer ever since. I also use pipx to
| install tools often. I really don't understand why you can't just
| pip install something globally. I want this package to be
| available to me EVERYWHERE, why can't I do it? I only use python
| recreationally because everyone uses python everywhere and you
| can't escape it. So there is a massive possibility I am simply
| wrong and pip-installing something globally is a huge risk. I'm
| just not understanding it.
| collinmanderson wrote:
| > I really don't understand why you can't just pip install
| something globally. I want this package to be available to me
| EVERYWHERE, why can't I do it? I only use python recreationally
| because everyone uses python everywhere and you can't escape
| it. So there is a massive possibility I am simply wrong and
| pip-installing something globally is a huge risk. I'm just not
| understanding it.
|
| You may have a library that's been globally installed, and you
| have multiple projects that rely on it. One day you may need to
| upgrade the library for use in one project, but there are
| backward incompatibile changes in the upgrade, so now all of
| your other projects break when you upgrade the global library.
|
| In general, when projects are used by multiple people across
| multiple computers, it's best to have the specific dependencies
| and versions specified in the project itself so that everyone
| using that project is using the exact same version of each
| dependency.
|
| For recreational projects it's not as big of a deal. It's just
| harder to do a recreation of your environment.
| zahlman wrote:
| > I want this package to be available to me EVERYWHERE, why
| can't I do it?
|
| Because it being available in the system environment could
| cause problems for system tools, which are expecting to find
| something else with the same name.
|
| And because those tools could include your system's package
| manager (like Apt).
|
| > So there is a massive possibility I am simply wrong and pip-
| installing something globally is a huge risk. I'm just not
| understanding it.
|
| I assume you're referring to the new protections created by the
| EXTERNALLY-MANAGED marker file, which will throw up a large
| boilerplate warning if you try to use pip to install packages
| in the system environment (even with --user, where they can
| still cause problems when you run the system tools without
| sudo).
|
| You should read one or more of:
|
| * the PEP where this protection was introduced
| (https://peps.python.org/pep-0668/);
|
| * the Python forum discussion explaining the need for the PEP
| (https://discuss.python.org/t/_/10302);
|
| * my blog post
| (https://zahlman.github.io/posts/2024/12/24/python-
| packaging-...) where I describe in a bit more detail (along
| with explaining a few other common grumblings about how Python
| packaging works);
|
| * my Q&A on Codidact
| (https://software.codidact.com/posts/291839/) where I explain
| more comprehensively;
|
| * the original motivating Stack Overflow Q&A
| (https://stackoverflow.com/questions/75608323/);
|
| * the Python forum discussion
| (https://discuss.python.org/t/_/56900) where it was originally
| noticed that the Stack Overflow Q&A was advising people to
| circumvent the protection without understanding it, and a
| coordinated attempt was made to remedy that problem.
|
| Or you can watch Brodie Robertson's video about the
| implementation of the PEP in Arch:
| https://www.youtube.com/watch?v=35PQrzG0rG4.
| aurintex wrote:
| I can only agree. I'm not an python expert, but I always
| struggled when installing a new package and got the warning, that
| it could break the system packages, or when cloning an existing
| repo on a new installed system. Always wondered, why it became so
| "complicated" over the years.
| zahlman wrote:
| > Always wondered, why it became so "complicated" over the
| years.
|
| Please see https://news.ycombinator.com/item?id=45753142.
| peter-m80 wrote:
| So basically a node-like thing for python
| talsperre wrote:
| uv is the best tool out there as long as you have python only
| dependencies. It's really fast, and you can avoid using poetry,
| pipenv, etc. The only reason for conda to still exist is non
| pythonic dependencies, but that's another beast to tackle in
| itself.
| samuel2 wrote:
| Reminds me of Julia's Pkg manager and the way Julia packages are
| managed (also with a .toml file). That's the way to go!
| eisbaw wrote:
| nix-shell is the OG
| zmmmmm wrote:
| > Instead of > > source .venv/bin/activate
| > python myscript.py > > you can just do
| > > > uv run myscript >
|
| This is by far the biggest turn off for me. The whole point of an
| environment manager is set the _environment_ so that the commands
| I run work. They need to run natively how they are supposed to
| when the environment is set, not put through a translation layer.
|
| _Side rant:_ yes I get triggered whenever someone tells me "you
| can just" do this thing that is actually longer and worse than
| the original.
| dragonwriter wrote:
| > They need to run natively how they are supposed to when the
| environment is set, not put through a translation layer.
|
| There is a new standard mechanism for specifying the same
| things you would specify when setting up a venv with a python
| version and dependencies _in the header of a single file
| script_ , so that tooling can setup up the environment and run
| the script using only the script file itself as a spec.
|
| uv (and PyPA's own pipx) support this standard.
|
| > yes I get triggered whenever someone tells me "you can just"
| do this thing that is actually longer and worse than the
| original.
|
| "uv run myscript" is neither longer nor worse than separately
| manually building a venv, activating it, installing
| dependencies into it, and then running the script.
| mborsuk wrote:
| From what I can tell (just started using uv) it doesn't break
| the original workflow with the venv, just adds the uv run
| option as well.
| wtallis wrote:
| Yes, you still have the option of manually activating a venv,
| and that makes sense if the amortized cost of that is lower
| than several instances of typing `uv run `. Though sometimes
| when working in one project with its venv activated, I end up
| needing to run a tool from another project with a separate
| vent, so uv _still_ ends up being useful.
| collinmanderson wrote:
| > The whole point of an environment manager is set the
| environment so that the commands I run work. They need to run
| natively how they are supposed to when the environment is set,
| not put through a translation layer.
|
| The `uv run` command is an optional shortcut for avoiding
| needing to activate the virtual environment. I personally don't
| like the whole "needing to activate an environment" before I
| can run commands "natively", so I like `uv run`. (Actually for
| the last 10 years I've had my `./manage.py` auto-set up the
| virtual environment for me.)
|
| The `uv add` / `uv lock` / `uv sync` commands are still useful
| without `uv run`.
| fireflash38 wrote:
| Unless I'm an AI, I'm pretty sure "uv run" is the same number
| of characters as "python". So it's shorter. Also venvs are a
| translation layer already, changing path.
| 1718627440 wrote:
| I typically type py<TAB>.
| zbentley wrote:
| > I get triggered whenever someone tells me "you can just" do
| this thing that is actually longer and worse than the original.
|
| Apologies for triggering you in advance, but in case you or
| others find it useful, here's how to do the equivalent env-
| activation commands with uv:
| https://news.ycombinator.com/item?id=44360892
| IshKebab wrote:
| You can still do the `source .venv/bin/activate` if you want.
|
| There's also `uv tool install` which will install things in
| your PATH without infecting your system with Python.
| hkt wrote:
| Am I the only one who thought poetry was still the greatest
| available whizbang?
| ModernMech wrote:
| Honestly though it's a pretty rough indictment of Python that the
| _best_ thing to happen in a decade is that people started writing
| Python tools in Rust. Not even a little Rust, uv is 98% Rust. I
| mean, they _just_ released 3.14 and that was supposed to be a
| pretty big deal.
| wiseowise wrote:
| Who cares what it is written in?
| ModernMech wrote:
| It's called dogfooding -- writing tools for the language in
| the language. Not doing so here, where the result is "best
| thing to happen to the ecosystem in a decade", is a tacit
| admission that Python isn't up for the task of writing best-
| in-class Python tooling (the use of Rust wasn't incidental).
| Having seen uv, people will probably start writing more
| Python-ecosystem projects in Rust.
|
| Which is fine, Python is not for everything.
| sunshowers wrote:
| Rust's rigorous separation of immutable and mutable state
| consistently leads to higher-quality software that stands the
| test of time.
| zahlman wrote:
| No, the "best thing that happened" (in TFA's author's opinion)
| is that this specific tool exists, with its particular design.
| Rust is an implementation detail. Most of the benefit that Uv
| offers over pip, in my analysis, is _not_ a result of being
| written in Rust.
|
| 3.14 _is_ a big deal.
| pansa2 wrote:
| I sometimes wonder if many core Python people don't actually
| like the language that much. That's why (a) they're constantly
| reinventing it, and (b) they celebrate rewrites from Python
| into other languages. Long before Rust, it was considered a
| good thing when a standard library module was rewritten in C.
|
| Compare this to the Go community, who celebrate rewrites from
| other languages _into_ Go. They rewrote their compiler in Go
| even though that made it worse (slower) than the original C
| version, because they enjoy using their own language and
| recognise the benefits of dogfooding.
| quantum_state wrote:
| Running pytest with uv run --active pytest... is very slow to get
| it started ... anyone has some tips on this?
| tonymet wrote:
| Can someone steelman the python tooling ecosystem for me? Having
| a new packaging / dependency manager every few years seems
| excessive.
| collinmanderson wrote:
| uv is finally an all-in-one tool that finally takes all of the
| good ideas from previous projects and combines them together to
| work well as one (and unbelievably fast).
|
| The fact that it's a binary, not written in python, also
| simplifies bootstrapping. So you don't need python+dependencies
| installed in order to install your python+dependencies.
| zahlman wrote:
| All of these tools are third-party and the Python core
| development team can't do anything to prevent people from
| inventing new ones. Even pip is technically at arms length; it
| has special support in the standard library (Python releases
| will vendor a wheel for it, which is designed to be able to
| bootstrap itself for installation[0]), but is developed
| separately.
|
| Standards are developed to allow existing tools to inter-
| operate; this entails allowing new tools to appear (and inter-
| operate), too.
|
| This system was in some regards deliberate, specifically to
| support competition in "build backends". The background here is
| that many popular Python projects must interface to _non_
| -Python code provided with the project; in many cases this is
| code in compiled languages (typically C, Fortran or Rust) and
| it's not always possible to pre-build for the user's system.
| This can get really, really complicated, and people need to
| connect to heavyweight build systems in some cases. The Python
| ecosystem standards are designed with the idea that installers
| can automatically obtain and use those systems when necessary.
|
| And by doing all of this, Python core developers get to focus
| on Python itself.
|
| Another important concern is that some bad choices were made
| initially with Setuptools, and we have been seeing a very long
| transition because of a very careful attitude towards backwards
| compatibility (even if it doesn't seem that way!) which in turn
| is motivated by the battle scars of the 2->3 transition. In
| particular, it used to be normal and expected that your project
| would use arbitrary Python code (in `setup.py` at the project
| root) _simply to specify metadata_. Further, `setup.py`
| generally expects to `import setuptools`, and might require a
| specific version of Setuptools; but it can 't _express_ its
| build-time Setuptools version requirement until the file is
| already running - a chicken-and-egg scenario.
|
| Modern projects use a declarative TOML file for "abstract"
| metadata instead (which is the source for concrete metadata
| included in the actual build artifacts), but the whole
| ecosystem still has to support a lot of really outdated ways of
| doing things, because in part of how much abandonware is out
| there.
|
| [0]: Wheels are zip-compressed, and Python can run code from a
| zip file, with some restrictions. The pip project is designed
| to make sure that this will work. The standard library provides
| a module "ensurepip" which locates this wheel and runs a
| bootstrap script from that wheel, which will then install into
| the current environment. Further, the standard library "venv",
| used to create virtual environments, defaults to using this
| bootstrap in the newly created environment.
| tonymet wrote:
| It's helpful context but still seems like a lost opportunity
| for python to provide the UI. It feels like every couple
| years we are reworking the wheel and redefining how to
| publish software.
|
| With python over the years i can think of pip, pipx,
| setuptools, easy_install, distutils, venv, conda, wheel,
| .egg, wheel (formats) , now uv.
|
| PHP stabilized with composer, perl with cpan , go with `go
| mod` and `go get` (builtin).
|
| Java and Swift had some competition with Gradle/maven and
| swiftPM / cocoapods, but nothing as egregious.
|
| file tree, dep tree, task DAG. how many ways can they be
| written?
| rieogoigr wrote:
| Is there a way to install this that doesn't involve piping a
| random URL to my shell interpreter?
| wiseowise wrote:
| Pip.
| zahlman wrote:
| Uv is available as a wheel from PyPI, so you can in fact `pip
| install uv` into an appropriate environment. Since it provides
| a command-line binary, Pipx will also happily install it into
| an environment it manages for you. And so on and so forth. (You
| can even install uv with uv, if you want to, for whatever
| reason.)
|
| The wheel basically contains a compiled ~53MB (huh, it's grown
| in recent versions) Rust executable and a few boilerplate files
| and folders to make that play nice with the Python packaging
| ecosystem. (It actually does create an importable `uv` module,
| but this basically just defines a function that tells you the
| path to the executable.)
|
| If you want it in your system environment, you may be out of
| luck, but check your full set of options at
| https://docs.astral.sh/uv/getting-started/installation/ .
|
| The install script does a ton of system introspection. It seems
| to be structured quite similarly to the Julia installer,
| actually.
| pshirshov wrote:
| And still there are some annoying issues:
| dependencies = [ "torch==2.8.0+rocm6.4",
| "torchvision==0.23.0+rocm6.4", "pytorch-triton-
| rocm==3.4.0", ... ]
|
| There is literally no easy way to also have a configuration for
| CUDA, you have to have a second config, and, the worse, manually
| copy/symlink them into the hardcoded pyproject.toml file
| sirfz wrote:
| Checkout dependency groups and uv conflicts configuration
| jillesvangurp wrote:
| Python is not my first language but I've always liked it. But
| project and dependency management was always a bit meh and an
| afterthought.
|
| Over the years, I've tried venv, conda, pipenv, petry, plain pip
| with requirements.txt. I've played with uv on some recent
| projects and it's a definite step up. I like it.
|
| Uv actually fixes most of the issues with what came before and
| actually builds on existing things. Which is not a small
| compliment because the state of the art before uv was pretty bad.
| Venv, pip, etc. are fine. They are just not enough by themselves.
| Uv embraces both. Without that, all we had was just a lot of
| puzzle pieces that barely worked together and didn't really fit
| together that well. I tried making conda + pipenv work at some
| point. Pipenv shell just makes using your shell state-full just
| adds a lot of complexity. None of the IDEs I tried figured that
| out properly. I had high hopes for poetry but it ended up a bit
| underwhelming and still left a lot of stuff to solve. Uv succeeds
| in providing a bit more of an end to end solution. Everything
| from having project specific python installation, venv by default
| without hassle, dependency management, etc.
|
| My basic needs are simple. I don't want to pollute my system
| python with random crap I need for some project. So, like uv, I
| need to have whatever solution deal with installing the right
| python version. Besides, the system python is usually out of date
| and behind the current stable version of python which is what I
| would use for new projects.
| nova22033 wrote:
| First time I tried to teach my son java, I realized how badly
| it's missing a built in dependency management system.
| warbaker wrote:
| Does uv handle CUDA versioning? This is the big reason I'm still
| on conda -- I can save a whole environment with `conda list
| --explicit`, including CUDA stuff, and I can set up a new machine
| with the same environment just from that file.
| aranw wrote:
| For years I've avoided using Python tools because I've always
| struggled to get them working properly. Will uv solve this pain
| for me? Can I install a Python app globally with it?
| alienbaby wrote:
| Can I just start using python if I've already got a bunch of
| projects manage with venv / pyenv / virtualenv ( and tbh I've
| kinda got into a confused mess with all these venv things, and at
| this point just hope they all keep working...)
| Areibman wrote:
| My biggest frustration is the lack of a good universal REPL to
| just play around with. It's frustrating how I have to run `uvx
| --with x,y,z ipython` every single time I just want to spin up
| some python code which may or may not use packages. (Hard to
| overstate how annoying it is to type out the modules list).
|
| To me, Python's best feature is the ability to quickly experiment
| without a second thought. Conda is nice since it keeps everything
| installed globally so I can just run `python` or iPython/Jupyter
| anywhere and know I won't have to reinstall everything every
| single time.
| embeng4096 wrote:
| Would creating a `main.py` with the dependencies installed
| either as a uv project or inline work for you?
|
| One thing I did recently was create a one-off script with
| functions to exercise a piece of equipment connected to the PC
| via USB, and pass that to my coworkers. I created a `main.py`
| and uv add'ed the library. Then when I wanted to use the script
| in the REPL, I just did `uv run python -i main.py`.
|
| This let me just call functions I defined in there, like
| `set_led_on_equipment(led='green', on=True)` directly in the
| REPL, rather than having to modify the script body and re-run
| it every time.
|
| Edit: another idea that I just had is to use just[0] and modify
| your justfile accordingly, e.g. `just pything` and in your
| justfile, `pything` target is actually `uv run --with x,y,z
| ipython`
|
| Edit edit: I guess the above doesn't even require just, it
| could be a command alias or something, I probably am
| overengineering that lol.
|
| [0]: https://github.com/casey/just
| forrestthewoods wrote:
| uv is spectacular
|
| But I'm utterly shocked that UV doesn't support "system
| dependencies". It's not a whole conda replacement. Which is a
| shame because I bloody hate Conda.
|
| Dependencies like Cuda and random C++ libraries really really
| ought to be handled by UV. I want a true genuine one stop shop
| for running Python programs. UV is like 80% of the way there. But
| the last 20% is still painful.
|
| Ideally UV would obsolete the need for docker. Docker shouldn't
| be a requirement to reliable run a program.
| eikenberry wrote:
| I either want one universal tool that can manage this sort of
| thing across multiple languages (eg. devenv) or a native, built-
| in tool (eg. go's tooling). I don't see how this is any different
| from all the previous incarnations of Python's project/package
| management tools. The constant churning of 3rd party tooling for
| Python was one of the main reasons I mostly stopped using it for
| anything but smaller scripts.
| 9dev wrote:
| The difference is that this one is actually good. So good, in
| fact, that there is considerable momentum and thus adoption
| with this tool, and I wouldn't be surprised if it reaches a
| similar state like npm is for node eventually.
| __mharrison__ wrote:
| The best things since f-strings...
|
| I'm teaching (strongly recommending/forcing using) uv in all my
| courses now.
| canto wrote:
| ffs, stop installing stuff by piping random scripts from the
| internet to shell!!1one
| didip wrote:
| UV indeed is a blessing. Love it. Hopefully it gets recommended
| as the official one.
| LtWorf wrote:
| It's VC backed. I have 100% confidence that it will end up
| badly.
| jonnycomputer wrote:
| How is this different than (or better than) pyenv?
| logicprog wrote:
| Uv existing is what made me willing to use Python as my primary
| prototype/experiment language!
| grigio wrote:
| yes
| fortran77 wrote:
| Why is it written in Rust though? I'd prefer a pure Python
| solution.
| richstokes wrote:
| I recently discovered you can use uv to run code direct from a
| git repo.
|
| No need to clone/manually install packages first. E.g. `uvx
| --from
| "git+https://github.com/richstokes/meshtastic_terminal.git"
| meshtastic-tui`
___________________________________________________________________
(page generated 2025-10-29 23:00 UTC)