Closed omgjlk closed 8 years ago
Thanks for working on this patch and thanks for your interest in the tool. But, with respect, I'm not feeling this proposal.
As an alternative, you can make virtualenvs in ~/.virtualenvs (or whatever specific location you are using) with any tool you like. Maybe there is need for a different interface for simply creating virtualenvs. If there is not that need, then virtualenv itself should be fine. If there is that need, I would not be against a separate tool just for that purpose and I would offer anyone whatever help they wanted to build and maintain that separate tool. I also suspect that some other existing virtualenv wrapper projects implement this.
--make is a shortcut to allow me to express ideas like 'make a virtualenv, run this command, then remove it'. In my mind, the added complexity was paid off by the high value. But it isn't intended to implement all possible use cases of virtualenv creation and I don't want to go there. I can't track all the options added to or removed from virtualenv which someone might want. There are a lot of them and there is some churn. Suppose we do all these options; by the time we are done, the resulting interface is more complicated than the tools we are wrapping. Then I don't see the point of having a wrapper. I would rather the default behavior of --make essentially track the default in the underlying tools. Hope that makes sense.
In some cases we want a virtaulenv without wheel support, so this commit exposes the virtualenv option (added in 13.0.0) to vex as a make option.