7 ms·

I recently switched to uv, and I cannot praise it enough. With uv, the Python ecosystem finally feels mature and polished rather than like a collection of brit

by heisig 2y ago

I recently switched to uv, and I cannot praise it enough. With uv, the Python ecosystem finally feels mature and polished rather than like a collection of brittle hacks. Kudos to the uv developers for creating such an amazing piece of software!

Wulfheart 2y ago
Ok, you convinced me to give it a try. Tbh, I am a casual user of python and I don't want to touch it unless I have a damn good reason to use it.
- mlnj 2y ago
  You do not need a damn good reason for this. Just try it out on a simple hello world. Then try it out on a project already using poetry for eg. uv init uv sync and you're done I'd say if you do not run into the pitfalls of a large python codebase with hundreds of dependencies, you'll not get the bigger argument people are talking about.
  - stavros 2y ago
    I don't think you need to sync, do you? It always just does it when running. That said, I do wish uv had `uv activate`. I like just working in the virtualenv without having to `uv run` everything.
    - hobofan 2y ago
      I do usually include instructions in our READMEs to do a `uv sync` as install command, in order to separate error causes, and also to allow for bootstrapping the venv so that it's available for IDEs.
      - stavros 2y ago
        That makes sense, thanks.
    - drcongo 2y ago
      You can still `source .venv/bin/activate(.fish)` and skip the uv run bit. I have Fish shell configured to automatically activate a .venv if it finds one in a directory I switch to.
      - stavros 2y ago
        I do do that, can you please share your fish script to autoload it? I have something for Poetry envs, but not venv dirs.
        drcongo 2y ago
        Sure thing - so I mostly ended up using this for activating a .venv in a fabfile directory using this... function __auto_fab --on-variable PWD iterm2_print_user_vars if [ -d "fabfile" ] if [ -d "fabfile/.venv" ] if not set -q done_fab and not set -q VIRTUAL_ENV echo -n "Starting fabfile venv... " pushd fabfile > /dev/null source .venv/bin/activate.fish --prompt="[fab]" popd > /dev/null set -g done_fab 1 echo -e "\r Fabfile venv activated " end else echo "Run gofab to create the .venv" end end end I've since deleted the one to do a .venv in this directory, but I think it was roughly this... function __auto_venv --on-variable PWD if [ -d ".venv" ] if not set -q done_venv echo -n "Starting venv... " source .venv/bin/activate.fish --prompt="[venv]" set -g done_venv 1 echo -e "\r Venv activated " end end end (just tested that and it seems to work - the --prompt actually gets overridden by the project name from uv's pyproject.toml now though so that's not really necessary, was useful at some point in the past) These live in ~/.config/fish/conf.d/events.fish
        stavros 2y ago
        Thank you!
        SAI_Peregrinus 2y ago
    - 0cf8612b2e1e 2y ago
      I keep going back and forth on ‘uv run’. I like being explicit with the tooling, but it feels like extra unneeded verbosity when you could just interact with the venv directly. Especially since I ported a bunch of scripts from ‘poetry run’
- jorvi 2y ago
  > I am a casual user of python and I don't want to touch it unless I have a damn good reason to use it. I... what? Python is a beautiful way to evolve beyond the troglodyte world of sh for system scripts. You are seriously missing out by being so pertinently against it.
  - OutOfHere 2y ago
    Just you wait till someone shows you how Rust is to Python what Python is to shell scripts. For one, null safety is a major issue in most corporate Python code, and much less of an issue in Rust code.
    - jorvi 2y ago
      Rust is decidedly not a scripting language. Don't get me wrong, Rust is great and I use it too, but for very different purposes than (system) scripts.
freeamz 2y ago
What about using https://github.com/RustPython/RustPython https://github.com/RustPython/RustPython also?
- the_mitsuhiko 2y ago
  Unlike uv this tool is unlikely to solve problems for the average Python user and most likely will create new ones.
  - freeamz 2y ago
    Agree, however for user who want to get faster speed out of python wouldn't that just work with rustpython? It can also run in the browser then.
    - chippiewill 2y ago
      RustPython is just an interpreter written in Rust. There's no reason why it would be meaningfully faster than CPython just because it's written in Rust rather than C. Rust adds memory safety, not necessarily speed. A new and immature interpreter is going to have other problems: - Lack of compatibility with CPython - Not up to date with latest version features - Incompatibility with CPython extensions RustPython is a cool project, but it's not reached the big time yet.
matsemann 2y ago
Yeah, switched to writing python professionally ~4 years ago, and been low key hating the ecosystem. From a java and javascript background, it's mostly been npm/mvn install and it "just works". With python, there's always someone being onboarded that can't get it to work. So many small issues. Have to have the correct version per project, then have to get the venv running. And then installing it needs to build stuff because there's no wheel, so need to set up a complete c++ and rust toolchain etc., just to pull a small project and run it. uv doesn't solve all this, but it's reduced the amount of ways things can go wrong by a lot. And it being fast means that the feedback-loop is much quicker.
- gunalx 2y ago
  I cannot share the same experiences. mvn is a buggy mess, randomly forgetting dependencies, and constantly needing a full clean to not die on itself. npm and the entire js ecosystem feels so immature with constant breaking changes, and circular dependency hell, when trying to uppgrade stuff.
  - Etheryte 2y ago
    That's an issue with the packages themselves though, not with package management as a whole. You and the comment above you are talking about different things. While there's plenty of pain to be had with npm, if you have a project that used to work years ago, you can generally just clone, install and be done, even if on older versions. On Python this used to mean a lot of hurt, often even if it was a fresh project that you just wanted to share with a colleague.
    - TeMPOraL 2y ago
      For value of "years" greater than 1? Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.
      - wfme 2y ago
amelius 2y ago
But how does it work with components that require libraries written in C? And what if there are no binaries yet for my architecture, will it compile them, including all the dependencies written in C?
- matrss 2y ago
  IMO if you require libraries in other languages then a pure python package manager like uv, pip, poetry, whatever, is simply the wrong tool for the job. There is _some_ support for this through wheels, and I'd expect uv to support them just as much as pip does, but they feel like a hack to me. Instead there is pixi, which is similar in concept to uv but for the conda-forge packaging ecosystem. Nix and guix are also language-agnostic package managers that can do the job.
  - amelius 2y ago
    But for example, if I install the Python package "shapely", it will need a C package named GEOS as a shared library. How do I ensure that the version of GEOS on my system is the one shapely wants? By trial and error? And how does that work with environments, where I have different versions of packages in different places? It sounds a bit messy to me, compared to a solution where everything is managed by a single package manager.
    - stabbles 2y ago
      You could use a package manager that packages C, C++, Fortran and Python packages, such as Spack: here's the py-shapely recipe [1] and here is geos [2]. Probably nix does similar. [1]: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/py-shapely/package.py#L64 https://github.com/spack/spack/blob/develop/var/spack/repos/... [2]: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/geos/package.py https://github.com/spack/spack/blob/develop/var/spack/repos/...
    - matrss 2y ago
      That's what I mean, in this case pip, uv, etc. are the wrong tool to use. You could e.g. use pixi and install all python and non-python dependencies through that, the conda-forge package of shapely will pull in geos as a dependency. Pixi also interoperates with uv as a library to be able to combine PyPI and conda-forge packages using one tool. But conda-forge packages (just like PyPI packages, or anything that does install-time dependency resolution really) are untestable by design, so if you care for reliably tested packages you can take a look at nix or guix and install everything through that. The tradeoff with those is that they usually have less libraries available, and often only in one version (since every version has to be tested with every possible version of its dependencies, including transitive ones and the interpreter). All of these tools have a concept similar to environments, so you can get the right version of GEOS for each of your projects.
ffsm8 2y ago
Now, if I hadn't read literally the same message for Pipenv/Pipfile and poetry before, too... Python is going through package managers like JS goes through trends like classes-everywhere, hooks, signals etc
- OutOfHere 2y ago
  There have been incremental evolutionary improvements that were brought forth by each of the packages you named. uv just goes a lot further than the previous one. There have been others that deserve an honorary mention, e.g. pip-tools, pdm, hatch, etc. It's going to be very hard for anything to top uv.

by heisig 2y ago

Wulfheart 2y ago

Ok, you convinced me to give it a try. Tbh, I am a casual user of python and I don't want to touch it unless I have a damn good reason to use it.

mlnj 2y ago
You do not need a damn good reason for this. Just try it out on a simple hello world. Then try it out on a project already using poetry for eg. uv init uv sync and you're done I'd say if you do not run into the pitfalls of a large python codebase with hundreds of dependencies, you'll not get the bigger argument people are talking about.
- stavros 2y ago
  I don't think you need to sync, do you? It always just does it when running. That said, I do wish uv had `uv activate`. I like just working in the virtualenv without having to `uv run` everything.
  - hobofan 2y ago
    I do usually include instructions in our READMEs to do a `uv sync` as install command, in order to separate error causes, and also to allow for bootstrapping the venv so that it's available for IDEs.
    - stavros 2y ago
      That makes sense, thanks.
  - drcongo 2y ago
    You can still `source .venv/bin/activate(.fish)` and skip the uv run bit. I have Fish shell configured to automatically activate a .venv if it finds one in a directory I switch to.
    - stavros 2y ago
      I do do that, can you please share your fish script to autoload it? I have something for Poetry envs, but not venv dirs.
      - drcongo 2y ago
        Sure thing - so I mostly ended up using this for activating a .venv in a fabfile directory using this... function __auto_fab --on-variable PWD iterm2_print_user_vars if [ -d "fabfile" ] if [ -d "fabfile/.venv" ] if not set -q done_fab and not set -q VIRTUAL_ENV echo -n "Starting fabfile venv... " pushd fabfile > /dev/null source .venv/bin/activate.fish --prompt="[fab]" popd > /dev/null set -g done_fab 1 echo -e "\r Fabfile venv activated " end else echo "Run gofab to create the .venv" end end end I've since deleted the one to do a .venv in this directory, but I think it was roughly this... function __auto_venv --on-variable PWD if [ -d ".venv" ] if not set -q done_venv echo -n "Starting venv... " source .venv/bin/activate.fish --prompt="[venv]" set -g done_venv 1 echo -e "\r Venv activated " end end end (just tested that and it seems to work - the --prompt actually gets overridden by the project name from uv's pyproject.toml now though so that's not really necessary, was useful at some point in the past) These live in ~/.config/fish/conf.d/events.fish
        stavros 2y ago
        Thank you!
      - SAI_Peregrinus 2y ago
  - 0cf8612b2e1e 2y ago
    I keep going back and forth on ‘uv run’. I like being explicit with the tooling, but it feels like extra unneeded verbosity when you could just interact with the venv directly. Especially since I ported a bunch of scripts from ‘poetry run’
jorvi 2y ago
> I am a casual user of python and I don't want to touch it unless I have a damn good reason to use it. I... what? Python is a beautiful way to evolve beyond the troglodyte world of sh for system scripts. You are seriously missing out by being so pertinently against it.
- OutOfHere 2y ago
  Just you wait till someone shows you how Rust is to Python what Python is to shell scripts. For one, null safety is a major issue in most corporate Python code, and much less of an issue in Rust code.
  - jorvi 2y ago
    Rust is decidedly not a scripting language. Don't get me wrong, Rust is great and I use it too, but for very different purposes than (system) scripts.

freeamz 2y ago

What about using https://github.com/RustPython/RustPython https://github.com/RustPython/RustPython also?

the_mitsuhiko 2y ago
Unlike uv this tool is unlikely to solve problems for the average Python user and most likely will create new ones.
- freeamz 2y ago
  Agree, however for user who want to get faster speed out of python wouldn't that just work with rustpython? It can also run in the browser then.
  - chippiewill 2y ago
    RustPython is just an interpreter written in Rust. There's no reason why it would be meaningfully faster than CPython just because it's written in Rust rather than C. Rust adds memory safety, not necessarily speed. A new and immature interpreter is going to have other problems: - Lack of compatibility with CPython - Not up to date with latest version features - Incompatibility with CPython extensions RustPython is a cool project, but it's not reached the big time yet.

matsemann 2y ago

Yeah, switched to writing python professionally ~4 years ago, and been low key hating the ecosystem. From a java and javascript background, it's mostly been npm/mvn install and it "just works". With python, there's always someone being onboarded that can't get it to work. So many small issues. Have to have the correct version per project, then have to get the venv running. And then installing it needs to build stuff because there's no wheel, so need to set up a complete c++ and rust toolchain etc., just to pull a small project and run it. uv doesn't solve all this, but it's reduced the amount of ways things can go wrong by a lot. And it being fast means that the feedback-loop is much quicker.

gunalx 2y ago
I cannot share the same experiences. mvn is a buggy mess, randomly forgetting dependencies, and constantly needing a full clean to not die on itself. npm and the entire js ecosystem feels so immature with constant breaking changes, and circular dependency hell, when trying to uppgrade stuff.
- Etheryte 2y ago
  That's an issue with the packages themselves though, not with package management as a whole. You and the comment above you are talking about different things. While there's plenty of pain to be had with npm, if you have a project that used to work years ago, you can generally just clone, install and be done, even if on older versions. On Python this used to mean a lot of hurt, often even if it was a fresh project that you just wanted to share with a colleague.
  - TeMPOraL 2y ago
    For value of "years" greater than 1? Node/NPM was a poster child of an ecosystem where projects break three times a week, due to having too many transitive dependencies that are being updated too often.
    - wfme 2y ago

amelius 2y ago

But how does it work with components that require libraries written in C? And what if there are no binaries yet for my architecture, will it compile them, including all the dependencies written in C?

matrss 2y ago
IMO if you require libraries in other languages then a pure python package manager like uv, pip, poetry, whatever, is simply the wrong tool for the job. There is _some_ support for this through wheels, and I'd expect uv to support them just as much as pip does, but they feel like a hack to me. Instead there is pixi, which is similar in concept to uv but for the conda-forge packaging ecosystem. Nix and guix are also language-agnostic package managers that can do the job.
- amelius 2y ago
  But for example, if I install the Python package "shapely", it will need a C package named GEOS as a shared library. How do I ensure that the version of GEOS on my system is the one shapely wants? By trial and error? And how does that work with environments, where I have different versions of packages in different places? It sounds a bit messy to me, compared to a solution where everything is managed by a single package manager.
  - stabbles 2y ago
    You could use a package manager that packages C, C++, Fortran and Python packages, such as Spack: here's the py-shapely recipe [1] and here is geos [2]. Probably nix does similar. [1]: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/py-shapely/package.py#L64 https://github.com/spack/spack/blob/develop/var/spack/repos/... [2]: https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/packages/geos/package.py https://github.com/spack/spack/blob/develop/var/spack/repos/...
  - matrss 2y ago
    That's what I mean, in this case pip, uv, etc. are the wrong tool to use. You could e.g. use pixi and install all python and non-python dependencies through that, the conda-forge package of shapely will pull in geos as a dependency. Pixi also interoperates with uv as a library to be able to combine PyPI and conda-forge packages using one tool. But conda-forge packages (just like PyPI packages, or anything that does install-time dependency resolution really) are untestable by design, so if you care for reliably tested packages you can take a look at nix or guix and install everything through that. The tradeoff with those is that they usually have less libraries available, and often only in one version (since every version has to be tested with every possible version of its dependencies, including transitive ones and the interpreter). All of these tools have a concept similar to environments, so you can get the right version of GEOS for each of your projects.

ffsm8 2y ago

Now, if I hadn't read literally the same message for Pipenv/Pipfile and poetry before, too... Python is going through package managers like JS goes through trends like classes-everywhere, hooks, signals etc

OutOfHere 2y ago
There have been incremental evolutionary improvements that were brought forth by each of the packages you named. uv just goes a lot further than the previous one. There have been others that deserve an honorary mention, e.g. pip-tools, pdm, hatch, etc. It's going to be very hard for anything to top uv.