Live data from Hacker News

Show HN: Metamon – A Vagrant/Ansible toolkit for kickstarting Django apps

blog.tryolabs.com

11–14 of 14 posts

Re: Show HN: Metamon – A Vagrant/Ansible toolkit for kickstarting Django apps

#11
post #2

I'm here to answer any questions and take feedback.

Without a good counterindication, I'll probably end up forking this and adding VirtualEnvWrapper because I like the workflow better than plain VirtualEnv. Is there any particular reason you don't include it? Perhaps the deployment automation mostly moots the VirtualEnvWrapper wins, making it not worth the increased complexity? P.S. This is a very timely release for me. I've done a few manual deploys of almost this ex…

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... [1] https://github.com/tryolabs/metamon/blob/master/deploy/roles...

Re: Show HN: Metamon – A Vagrant/Ansible toolkit for kickstarting Django apps

#12

Earlier quoted context omitted.

Without a good counterindication, I'll probably end up forking this and adding VirtualEnvWrapper because I like the workflow better than plain VirtualEnv. Is there any particular reason you don't include it? Perhaps the deployment automation mostly moots the VirtualEnvWrapper wins, making it not worth the increased complexity? P.S. This is a very timely release for me. I've done a few manual deploys of almost this ex…

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 m…

That'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.

Re: Show HN: Metamon – A Vagrant/Ansible toolkit for kickstarting Django apps

#14
post #13

Question here. Assuming I am developing something in pure Python, is there any advantage to using Vagrant if I already have a Virtualenv setup? They are the same principle of isolated environments, but implemented at different levels.

It really depends on what you're doing. If you're working on multiple projects that depend on other services to be running then it probably helps to use Vagrant. If you just need libs virtualenv is enough.
Post reply on HN