Autoenv VS not-a-package-manager

the way I manage (2) is with a kind of DIY pipenv system i've come up with. i have a tool installed in my terminal called autoenv. when i navigate to a new directory, if there's a .env file in it, autoenv executes it. that's basically all autoenv does. I have a .env in my home folder that, among other things, activates my "master" venv. when I create a new project that I want to have its own venv, I just add a .env file to that folder to activate it. otherwise, the master venv is active whenever I roam around my filesystem, functionally serving as a default environment i reuse.

Inspired by autoenv, pyautoenv hooks into the cd command in your shell and will automatically activate a poetry or venv Python environment if that environment is defined in the directory you're cd-ing into. Zsh, Bash, and PowerShell are supported.

There is an autoenv tool you can use to automatically activate a python virtualenv when you cd into a directory but it’s a little annoying to set up https://github.com/hyperupcall/autoenv

But IMO the best solution by far is to use autoenv. There is autoenv for bash and autoenv for zsh.

Another bespoke solution I use is napm ("not a package manager"), which allows me to reuse poorly structured git dependencies (I work with a lot of research code written by people who are researchers first and engineers second).