3 ms·
This defeats one of the coolest parts of virtualenvs which is that they can be placed anywhere. It’s just a directory.
by whalesalad 4y ago
This defeats one of the coolest parts of virtualenvs which is that they can be placed anywhere. It’s just a directory.
- tedivm 4y agoThis pep already partially does that. > The error message SHOULD inform the user that a virtual environment is required, SHOULD provide shell-specific instructions on how to create and activate a virtual environment named .venv, and SHOULD provide a link to a documentation page that explains how to create and activate a virtual environment.
- meandmycode 4y agoWhy do you say this is one of the coolest part?
- whalesalad 4y agoBecause the best part about unix/linux is that everything is a file (or more broadly, everything are files and folders) and this is congruent with that. The more I program, the more I appreciate: - 1. tools that are extremely small and functional and can be composed together (re: unix pipes, cat foo | grep bar) - 2. things that are just files and folders on disk, so that they can get introspected, moved to different disks, symlinked, put on FUSE filesystems, etc. The common interface of file or folder is very flexible.
- twic 4y agoNothing about that proposal changes how venvs work. It just changes what the global python command does. Anything you do explicitly with a venv today, you could still do under that proposal.
- DangitBobby 4y agoI'd call this a minor convenience at best. Symlinks would still make it possible, of course.
- whalesalad 4y agoI know it's not the end of the world, but I prefer to keep my dependencies outside of the project root in deployed scenarios. Ex, /srv/venv and /srv/app