2 ms·
Shawn, There isn't really a reason not to use Virtualenv wrapper, but there is also not really a reason to use it. Activating it is rather simple, so I just di
by maurodec 12y ago
Shawn,
There isn't really a reason not to use Virtualenv wrapper, but there is also not really a reason to use it. Activating it is rather simple, so I just didn't really want to add something else to the installation (that would make it slightly more complex and slower). However, take a look at the development role[0], it actually activates the Virtualenv on login.
If you're going to be logging into the production machines (where the development role does not make (total) sense to have) you may want to install it, or turn off everything in the development role[1] except virtualenv activation and add it to those machines.
In short, I'm not against it, I just think it's not needed since the development role makes it redundant to have.
[0] https://github.com/tryolabs/metamon/blob/master/deploy/roles/development/tasks/venv.yml https://github.com/tryolabs/metamon/blob/master/deploy/roles...
[1] https://github.com/tryolabs/metamon/blob/master/deploy/roles/development/tasks/main.yml https://github.com/tryolabs/metamon/blob/master/deploy/roles...
- shawn-furyan 12y agoThat's in the ballpark of the reasoning I expected. Thanks for the reply and the specific pointers. I tend to develop from the command line and have heretofore deployed manually, so I've found the subtle streamlining offered by VirtualEnvWrapper to be worthwhile. However, I think I'll try to go without it initially to reexamine its value under more automated deployment. Also, this change would mostly serve as an incentive to ssh onto production servers, which is usually not going to be the optimal solution to issues that arise. I hadn't really thought about it this way until your comment.