4 ms·

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
        I'm not them, but I use `direnv` for this. Their wiki includes two layout_uv[1] scripts, one that uses `uv` just to activate a regular venv and a second that uses it to manage the whole project. I use the latter. [1] https://github.com/direnv/direnv/wiki/Python https://github.com/direnv/direnv/wiki/Python
  - 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.

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
      I'm not them, but I use `direnv` for this. Their wiki includes two layout_uv[1] scripts, one that uses `uv` just to activate a regular venv and a second that uses it to manage the whole project. I use the latter. [1] https://github.com/direnv/direnv/wiki/Python https://github.com/direnv/direnv/wiki/Python
- 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.