For those of you who install your virtual environments into a global directory (e.g. virtualenvwrapper users, `$WORKON_HOME`), what's the primary reason you do that instead locally into your workspace (e.g. `.venv` directory next to your code)?
Easy to delete all environments
7.4%
Environment sharing/reuse
24.2%
No reason/habit/tool default
52.6%
Other (w/ follow-up comment to explain)
15.8%
Poll ended at .

@brettcannon Similar to @ogimoore I tend to keep a couple of environments with different versions of Python around.

I also do mostly library development so I'm interested in how changes to library A affects library B and how both interact in application C.

Under this workflow it in very non-obvious which of those source checkouts should "own" the env and installing things N**2 times (each project in each other projects env) seems overkill.

Maybe this should have been "sharing/reuse", but 🤷

@tacaswell I would have put that under "sharing/reuse" as that's the primary reason you have structured things this way.

Does this mean you typically have a checkout associated with a single environment? Or at least only one environment per Python version? IOW how could a tool ever know which environment you meant to be used (potentially by Python version)?

BTW I'm also happy with, "it's not possible" as you're obviously a power user. 😅

@brettcannon I tend to have my "bleeding" environment with I build from the main branch of as many things as I can (starting at CPython and going up), and then a bunch `dd3x` environments per python version (via Arch + AUR I have py34 - py311 available).

I think of envs as a per-terminal thing and tend to have multiple terminals open. I will (editable) install a checkout into more than one venv if I have to and select the venv by what terminal I am on (independent of the cwd).

@brettcannon I guess the tool knows what env I want because I tell it 🤣
@tacaswell Yep, you're ending up in the "I can't help make your life easier" camp 😉

@brettcannon That is one step better than I am doing to myself were I keep trying to make my life harder: https://github.com/tacaswell/build_the_world

But seriously, please do not make this sort of workflow _worse_.

Super opinionated tools are great until they are utterly unusable. Assuming all Python development is fundamentally application-like and propagating those patterns as general Python "best practices" worries me (and I do not think writing off all library developers as "power users" is fair either).

GitHub - tacaswell/build_the_world: Scripts to build much of the Scipy ecosystem from source.

Scripts to build much of the Scipy ecosystem from source. - tacaswell/build_the_world

GitHub

@tacaswell I'm not sure what hat you think I'm wearing here, but it's for https://github.com/brettcannon/python-launcher which is a personal project, so you don't have to use it. And even in context of the Python Launcher for Unix, I'm thinking of https://github.com/brettcannon/python-launcher/discussions/168 and https://github.com/brettcannon/python-launcher/discussions/222 which increases the flexibility to potentially support you.

But I also can't write code to read minds, so I'm trying to figure out how much people's workflows require thought vs just happen to lack some easy automation.

GitHub - brettcannon/python-launcher: Python launcher for Unix

Python launcher for Unix. Contribute to brettcannon/python-launcher development by creating an account on GitHub.

GitHub
@brettcannon Your wearing the Brett Cannon hat so lots of people will listen to you :)

@tacaswell Mastadon might have more characters to use than some of us are used to, but it still isn't infinite to always explain which 🤠 I'm wearing. 😉

I'm unfortunately also being a bit vague on purpose as I want to conceptually understand the environment workflow people have instead of what tools people use. I want the "what do I need" answers instead of "what I use".