My reply here is to people reading along. I know you know this stuff.
Yeah, I can imagine hacking something together on my own if I had to ("first run `zfs create tank/myproject`...") but I'm glad I don't. I'm not referring to the person here, but I've seen people go to great lengths to avoid virtualenvs when they're about as lightweight as such a thing can possibly be. Like, this is the entire process for using one in a project:
Now if you run `pip install foo` in that shell, it'll install the package inside that virtualenv. If your code has `import foo` somewhere, it'll load the virtualenv's package, no matter what versions of foo are installed elsewhere. It's nearly identical in concept to Node's ./node_modules directories, except that you have to explicitly activate the virtualenv, which also gives you the flexibility to easily use the same venv for multiple projects if you really want to.
If you have something like mise or uv, you can ask them to manage a venv for you, but they're conceptually just wrappers around those steps.
Yeah, I can imagine hacking something together on my own if I had to ("first run `zfs create tank/myproject`...") but I'm glad I don't. I'm not referring to the person here, but I've seen people go to great lengths to avoid virtualenvs when they're about as lightweight as such a thing can possibly be. Like, this is the entire process for using one in a project:
Now if you run `pip install foo` in that shell, it'll install the package inside that virtualenv. If your code has `import foo` somewhere, it'll load the virtualenv's package, no matter what versions of foo are installed elsewhere. It's nearly identical in concept to Node's ./node_modules directories, except that you have to explicitly activate the virtualenv, which also gives you the flexibility to easily use the same venv for multiple projects if you really want to.If you have something like mise or uv, you can ask them to manage a venv for you, but they're conceptually just wrappers around those steps.