9 ms·

Things i love about uv/astral - Putting .venv automatically into the project directory - Installing dependencies with pyproject.toml - Installing any Python

Things i love about uv/astral - Putting .venv automatically into the project directory - Installing dependencies with pyproject.toml - Installing any Python version - Fast pip installs - uvx (like npx) - Ruff formatter and linter, made by the same people Python used to give me a headache, now I tend to reach for it more often, exclusively thanks to uv

wiseowise 2y ago
I concur. Python was essentially dead for me outside of simple scripts, because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? Now it's python3 -m pip3 install --user uv; uv init; uv add <package> and I'm good to go. Or amazing uvx <package>. Finally someone understands how it is supposed to be done.
- mickeyp 2y ago
  As opposed to: `python3 -m pip install <package>' to install it? And `python3 -m <package>' to run it?
  - wiseowise 2y ago
    You forgot to initialize venv and activate it. And now also do it on other dev's machine shared via git.
    - mickeyp 2y ago
      They are one-offs, much like your init command. You do not have to activate it: you can explicitly invoke the binary in the venv if you do not want this.
      - wiseowise 2y ago
        I spawn dozens of one-offs, cost adds up. Some of those evolve to not be one-offs, and then synchronization with other devs becomes a problem.
        zahlman 2y ago
        You still use it only once per project in normal workflows. And if you need to go beyond that, you'd have the same problem with Rust, at a minimum; it can't read your mind and install into the correct venv. It only seems to be doing that because it made one and assumes it will use that one. If you like the per-project venv workflow, and like having it in a specific place (whether that's relative to the project root, or a parallel named venv in `~/.local` somewhere, or anything else), you can set that up as part of your project initialization, too. Going back to your first comment: > because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? This complaint makes little sense because it mixes and matches things from different categories. `pyproject.toml` isn't even a tool, but a config file that several other tools will rely on - including uv. Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers". Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!)
        wiseowise 2y ago
        As wise Red from the Shawshank Redemption said: https://tenor.com/4bSA.gif https://tenor.com/4bSA.gif > This complaint makes little sense because it mixes and matches things from different categories. It makes all the sense, because I don’t want or have to give a shit about all of this crap. > `pyproject.toml` isn't even a tool, but a config file And how many of current tools understand it? Can I make pip save dependencies in it out of the box? No? Then it stays in bullshit list. Arguably it became much better these days, but I remember constant friction when pyproject.toml was just introduced. > Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers". Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!) Mistake is having thousands of disjoint tools that are stitched together with sticks and shit. I’m glad most modern programming communities got fed up with this crap and lean towards new generation of tooling that can do everything. I’m absolutely fed up and loathe stitching together billions of half working shite to get semi decent working environment. Environment management, testing, formatting, libraries and building in one tool should be a minimum requirement.
  - dagw 2y ago
    'python3 -m pip install <package>' to install it? Won't update your pyproject.toml and lock file 'python3 -m <package>' to run it? Won't install the dependencies you need or set up an insolated environment <package>. 'uvx <package>' will create a venv, make sure you have all the dependencies that <package> needs and run <package>
- nchmy 2y ago
  Even better, use mise to install uv and all your other tooling
  - HumanOstrich 2y ago
    Hey a fellow mise user in the wild! I use it everywhere now for both personal and work projects. Cheers!
- wakawaka28 2y ago
  Never have I used "python -m" to run pip. Never in 20 years of using Python. I think you're imagining problems to gripe more about pip. Not that pip is perfect but we truly don't need anything else. It could turn out nice but I think having to learn Rust will turn off most people in the Python community when it comes to contributing.
  - wiseowise 2y ago
    Pip is a nightmare to use, compared to npm, and the only thing that caught your eye is “python3 -m pip” instead of pip3? Seriously?
    - wakawaka28 2y ago
      I never had much trouble using pip. I only pointed out that gripe as evidence that the dude saying it probably isn't using pip or else he is extremely eccentric in a way that would cause issues eventually.
amai 2y ago
I only don't like the .venv in the project directory. It tends to get copied into git or docker. And it makes backup of a project a lot bigger and taking longer because of the many files.
- OutOfHere 2y ago
  You shouldn't be making a backup of what's already in a remote git repo.
- mirashii 2y ago
  .gitignore and .dockerignore exist.
- zahlman 2y ago
  I don't know what's gone wrong with your Git setup (and I don't use Docker), but dotfiles (thus, a `.venv` folder) should be getting gitignored by default. (If all else fails, you can just add a `.gitignore` with just `*` to the venv.)
- dagw 2y ago
  Uv doesn't require .venv in the project directory, it's just the default. If you have a good reason why it doesn't work for your setup, you can place the venv dir anywhere and still use uv.
zahlman 2y ago
There's this weird disconnect I've noticed whenever people talk about Python project management tools in general, and especially about UV. When they talk about why they like the tool, they say things like "it's not itself written in Python" (sometimes they even seem to think Rust specifically is important), and "it's an all-in-one integrated tool that takes care of all my needs". But when they talk about what they like about the tool, it's stuff that doesn't actually depend on the prior facts. People have lots of different ideas about where venvs should go. Choosing an entire tool suite because it agrees with you on this point seems rather sketchy to me. (Obviously you specifically have other reasons, but still.) Managing venvs isn't hard. I use a couple of shell functions in my .bash_aliases to do it the way I want: # Activate the local venv, which is specially named/located. alias activate-local="source .local/.venv/bin/activate" # Run an acceptance test in the local private folder. alias try-it="(cd .local/ && source run-acceptance-test)" # PIP (the pipx-installed copy) in the current Environment. pipe() { if [ -z ${VIRTUAL_ENV+x} ] then echo "No venv active; use pip instead" else ~/.local/bin/pip --python `which python` "$@" fi } And then I use a simple Python wrapper to create the venv and do an editable install into it. ("Installing dependencies with pyproject.toml" is already supported in Pip, assuming you mean the project's runtime dependencies: `pip install -e .`. Support for other dependency groups defined by new PEPs will hopefully come soon.) There's no reason Ruff couldn't be a separate tool, mixed and matched with the tools used for other parts of the development process. That's already how people used Black. Similarly for most of the other jobs. In my book, prefixing `uv tool` to a command line is noise; I don't see how it's better than having separate tools. What you really get from a tool suite is an opinion about which to use. The issues with Pip don't result from it being written in Python. They result from internal design flaws - partly just generic technical debt, but largely the long-standing assumption that you'll just copy Pip to each environment. (There's code out there that tries to use `subprocess` to run Pip even after the wheel is nominally installed; this isn't assured to work! There's also code that tries to use Pip's API, even though that doesn't actually exist and will break without warning or documentation.) Current versions of Pip have much better support for installing into a different environment from where it's located (which is part of what makes Pipx possible), but awareness is low, and `--without-pip` is not the default for `venv` (that would be really disruptive). Even slow package resolution is, as far as I can tell, mostly not because of Pip's Python code running slowly. It has more to do with suboptimal caching behaviours and the fact that the metadata standards are so poorly done, and perhaps just some algorithmic issues. But a ton of that work is IO-bound, especially if you have to use sdists for anything (getting accurate metadata tends to involve downloading the entire sdist and building the project, even if it turns out not to be the version that should be installed).

wiseowise 2y ago

I concur. Python was essentially dead for me outside of simple scripts, because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? Now it's python3 -m pip3 install --user uv; uv init; uv add <package> and I'm good to go. Or amazing uvx <package>. Finally someone understands how it is supposed to be done.

mickeyp 2y ago
As opposed to: `python3 -m pip install <package>' to install it? And `python3 -m <package>' to run it?
- wiseowise 2y ago
  You forgot to initialize venv and activate it. And now also do it on other dev's machine shared via git.
  - mickeyp 2y ago
    They are one-offs, much like your init command. You do not have to activate it: you can explicitly invoke the binary in the venv if you do not want this.
    - wiseowise 2y ago
      I spawn dozens of one-offs, cost adds up. Some of those evolve to not be one-offs, and then synchronization with other devs becomes a problem.
      - zahlman 2y ago
        You still use it only once per project in normal workflows. And if you need to go beyond that, you'd have the same problem with Rust, at a minimum; it can't read your mind and install into the correct venv. It only seems to be doing that because it made one and assumes it will use that one. If you like the per-project venv workflow, and like having it in a specific place (whether that's relative to the project root, or a parallel named venv in `~/.local` somewhere, or anything else), you can set that up as part of your project initialization, too. Going back to your first comment: > because of constant friction: pip, pyenv, poetry, pyproject.toml, rye - wtf? This complaint makes little sense because it mixes and matches things from different categories. `pyproject.toml` isn't even a tool, but a config file that several other tools will rely on - including uv. Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers". Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!)
        wiseowise 2y ago
        As wise Red from the Shawshank Redemption said: https://tenor.com/4bSA.gif https://tenor.com/4bSA.gif > This complaint makes little sense because it mixes and matches things from different categories. It makes all the sense, because I don’t want or have to give a shit about all of this crap. > `pyproject.toml` isn't even a tool, but a config file And how many of current tools understand it? Can I make pip save dependencies in it out of the box? No? Then it stays in bullshit list. Arguably it became much better these days, but I remember constant friction when pyproject.toml was just introduced. > Poetry and Rye are specifically trying to do the same thing uv is - in fact, Rye is uv's predecessor. Pyenv is for making separate installations of Python - it works alongside venvs, not as an alternative. Pip is just an installer; it's not meant to be compared to full project workflow tools or even to just "package managers". Expecting one tool to work for everyone is a mistake because of the sheer variety of use cases out there. At the very least, people who only want to install Python applications and libraries are very different from those who seek to distribute their own work. (People in the first group might not even write Python code!) Mistake is having thousands of disjoint tools that are stitched together with sticks and shit. I’m glad most modern programming communities got fed up with this crap and lean towards new generation of tooling that can do everything. I’m absolutely fed up and loathe stitching together billions of half working shite to get semi decent working environment. Environment management, testing, formatting, libraries and building in one tool should be a minimum requirement.
- dagw 2y ago
  'python3 -m pip install <package>' to install it? Won't update your pyproject.toml and lock file 'python3 -m <package>' to run it? Won't install the dependencies you need or set up an insolated environment <package>. 'uvx <package>' will create a venv, make sure you have all the dependencies that <package> needs and run <package>
nchmy 2y ago
Even better, use mise to install uv and all your other tooling
- HumanOstrich 2y ago
  Hey a fellow mise user in the wild! I use it everywhere now for both personal and work projects. Cheers!
wakawaka28 2y ago
Never have I used "python -m" to run pip. Never in 20 years of using Python. I think you're imagining problems to gripe more about pip. Not that pip is perfect but we truly don't need anything else. It could turn out nice but I think having to learn Rust will turn off most people in the Python community when it comes to contributing.
- wiseowise 2y ago
  Pip is a nightmare to use, compared to npm, and the only thing that caught your eye is “python3 -m pip” instead of pip3? Seriously?
  - wakawaka28 2y ago
    I never had much trouble using pip. I only pointed out that gripe as evidence that the dude saying it probably isn't using pip or else he is extremely eccentric in a way that would cause issues eventually.

amai 2y ago

I only don't like the .venv in the project directory. It tends to get copied into git or docker. And it makes backup of a project a lot bigger and taking longer because of the many files.

OutOfHere 2y ago
You shouldn't be making a backup of what's already in a remote git repo.
mirashii 2y ago
.gitignore and .dockerignore exist.
zahlman 2y ago
I don't know what's gone wrong with your Git setup (and I don't use Docker), but dotfiles (thus, a `.venv` folder) should be getting gitignored by default. (If all else fails, you can just add a `.gitignore` with just `*` to the venv.)
dagw 2y ago
Uv doesn't require .venv in the project directory, it's just the default. If you have a good reason why it doesn't work for your setup, you can place the venv dir anywhere and still use uv.

zahlman 2y ago

There's this weird disconnect I've noticed whenever people talk about Python project management tools in general, and especially about UV. When they talk about why they like the tool, they say things like "it's not itself written in Python" (sometimes they even seem to think Rust specifically is important), and "it's an all-in-one integrated tool that takes care of all my needs". But when they talk about what they like about the tool, it's stuff that doesn't actually depend on the prior facts. People have lots of different ideas about where venvs should go. Choosing an entire tool suite because it agrees with you on this point seems rather sketchy to me. (Obviously you specifically have other reasons, but still.) Managing venvs isn't hard. I use a couple of shell functions in my .bash_aliases to do it the way I want: # Activate the local venv, which is specially named/located. alias activate-local="source .local/.venv/bin/activate" # Run an acceptance test in the local private folder. alias try-it="(cd .local/ && source run-acceptance-test)" # PIP (the pipx-installed copy) in the current Environment. pipe() { if [ -z ${VIRTUAL_ENV+x} ] then echo "No venv active; use pip instead" else ~/.local/bin/pip --python `which python` "$@" fi } And then I use a simple Python wrapper to create the venv and do an editable install into it. ("Installing dependencies with pyproject.toml" is already supported in Pip, assuming you mean the project's runtime dependencies: `pip install -e .`. Support for other dependency groups defined by new PEPs will hopefully come soon.) There's no reason Ruff couldn't be a separate tool, mixed and matched with the tools used for other parts of the development process. That's already how people used Black. Similarly for most of the other jobs. In my book, prefixing `uv tool` to a command line is noise; I don't see how it's better than having separate tools. What you really get from a tool suite is an opinion about which to use. The issues with Pip don't result from it being written in Python. They result from internal design flaws - partly just generic technical debt, but largely the long-standing assumption that you'll just copy Pip to each environment. (There's code out there that tries to use `subprocess` to run Pip even after the wheel is nominally installed; this isn't assured to work! There's also code that tries to use Pip's API, even though that doesn't actually exist and will break without warning or documentation.) Current versions of Pip have much better support for installing into a different environment from where it's located (which is part of what makes Pipx possible), but awareness is low, and `--without-pip` is not the default for `venv` (that would be really disruptive). Even slow package resolution is, as far as I can tell, mostly not because of Pip's Python code running slowly. It has more to do with suboptimal caching behaviours and the fact that the metadata standards are so poorly done, and perhaps just some algorithmic issues. But a ton of that work is IO-bound, especially if you have to use sdists for anything (getting accurate metadata tends to involve downloading the entire sdist and building the project, even if it turns out not to be the version that should be installed).