You can source the virtualenv like normal.

For any command, you can create an 'alias' in your shell config. That way you can get rid of the prefix.

Solved with direnv. Also - in my .bashrc in all of my (many) clients:

  $ type uvi uvl uvv
  uvi is a function
  uvi ()
  {
      uv pip install $@
  }
  uvl is a function
  uvl ()
  {
      uv pip list
  }
  uvv is a function
  uvv ()
  {
      uv venv;
      cat > .envrc <<EOF
  source .venv/bin/activate
  EOF

      direnv allow
  }

That would defeat the purpose of creating and expanding their brand.

direnv, .envrc, "layout uv"

https://github.com/direnv/direnv/wiki/Python#uv

alias in ~/.zshrc?

uv run bash/zsh/your shell of choice

You're welcome to live in the 90s dark ages, I feel this attitude and the shape of the old linux distros like Debian that laboriously re-package years-old software have been one of the biggest failures of open source and squandered untold hours of human effort. It's a model that works okay for generic infrastructure but requires far too much labor and moves far too slowly with quite a poor experience for end users and developers. Why else would all modern software development (going back to perl's cpan package manager in 1995) route around it?

Do you not use non-OS package managers?

If not, do you develop software with source dependencies (go, java, node, rust, python)? If so, how do you handle acquiring those dependencies—by hand or using a tool?

I very much appreciate the sentiment - and agree that random crap (particularly some of the insane dependency chains that you get from NPM, but also Rust) in which you go to install a simple (at least you believe) package - and the Rust/NPM manager downloads several hundred dependencies.

But the problem with only using the OS package manager is that you then lock yourself out of the entire ecosystem of node, python, rust packages that have never been migrated to whatever operating system you are using - which might be very significant.

How do you feel about Nix? It feels like this is a nice half-way measure between reliable/reproducible builds, but without all of the Free For all where you are downloading who-knows-what-from-where onto your OS?

In general I agree with you. But not for software dev packages.

The package manager I use, apt on Debian, does not package many Python development repos. They've got the big ones, e.g. requests, but not e.g. uuid6. And I wouldn't want it to - I like the limited Debian dev effort to be put towards the user experience and let the Python dev devs worry about packaging Python dev dependencies.

What’s the point of constraining oneself to what is in the OS package manager? I like to keep my dependencies up to date. The versions in the OS package manager are much older.

And let’s say you constrain yourself to your OS package manager. What about the people on different distros? Their package managers are unlikely to have the exact same versions of your deps that your OS has.

Don't worry, gramps, pip won't trigger your tinfoil hat.

Then don't use it?

Do you use pip?