[Python-ideas] npm-style venv-aware launcher

[Andrew Barnert]

On May 31, 2015, at 01:01, David Townshend <aquavitae69 at gmail.com> wrote:
> 
> 
>> On Sun, May 31, 2015 at 9:35 AM, Andrew Barnert <abarnert at yahoo.com> wrote:
>>> On May 31, 2015, at 00:16, David Townshend <aquavitae69 at gmail.com> wrote:
>>> 
>>> Pip and venv have done a lot to improve the accessibility and ease of installing python packages, but I believe there is still a lot of room for improvement.  I only realised how cumbersome I find working with python packages when I recently spent a lot of time on a javascript project using npm.  A bit of googling and I found several articles discussing pip, venv and npm, and all of them seemed to say the same thing, i.e. pip/venv could learn a lot from npm.
>>> 
>>> My proposal revolves around two issues:
>>> Setting up and working with virtual environments can be onerous.  Creating one is easy enough, but using them means remembering to run `source activate` every time, which also means remembering which venv is used for which project.  Not a major issue, but still and annoyance.
>> 
>> If you're not using virtualenvwrapper.
>> 
>> You do have to get used to using workon instead of cd to switch between environments--although if you want to, there's a hook you can alias cd to (virtualenvwrapperhelper). And I haven't tried either the native Windows cmd or PowerShell ports or the PowerShell port (it works great with MSYS bash, but I realize not everyone on Windows wants to pretend they're not on Windows). And managing multiple environments with different Python versions (at least different versions of 2.x or different versions of 3.x) could be nicer.
>> 
>> But I think it does 90% of what you're looking for, and I think it might be easier to add the other 10% to virtualenvwrapper than to start from scratch. And it works with 2.6-3.3 as well as 3.4+ (with virtualenv instead of venv, of course), on most platforms. with multiple environments, with tab completion (at least in bash and zsh), etc.
> 
> Virtualenvwrapper does help a bit, but nowhere near 90%.  It doesn't touch any of the issues with pip, it still requires configuration and manually ensuring that the venv is activated. 

As I already mentioned, if you use virtualenvwrapperhelper or autoenv, you don't need to manually ensure that the venv is activated. I personally use it by having workon cd into the directory for me instead of vice-versa, but if you like vice-versa, you can do it that way, so every time you cd into a directory with a venv in, it activates.

> But the biggest issue with extending it is that it has a totally different workflow philosophy in that it enforces a separation between the venv and the project,

I don't understand what you mean. I have a one-to-one mapping between venvs and projects (although you _can_ have multiple projects using the same venv, that isn't the simplest way to use it), and I have everything checked into git together, and I didn't have to do anything complicated to get there.

> whereas my proposal involves more integration of the two.  I have used virtualenvwrapper quite a bit in the past, but in the end I've always found it easier to just work with venv because of the lack of flexibiltiy in where and how I store the venvs.  

The default for npm is that your package dir is attached directly to the project. You can get more flexibility by setting an environment variable or creating a symlink, but normally you don't. It has about the same flexibility as virtualenvwrapper, with about the same amount of effort. So if virtualenvwrapper isn't flexible enough for you, my guess is that your take on npm won't be flexible enough either, it'll just come preconfigured for your own idiosyncratic use and everyone else will have to adjust...
>>> Managing lists of required packages is not nearly as easy as in npm since these is no equivalent to `npm install --save ...`.  The best that pip offers is `pip freeze`.  Howevere, using that is a) an extra step to remember and b) includes all implied dependencies which is not ideal.
>>> My proposal is to use a similar model to npm, where each project has a `venvrc` file which lets python-related tools know which environment to use.  In order to showcase the sort of funcionality I'm proposing, I've created a basic example on github (https://github.com/aquavitae/pyle).  This is currently py3.4 on linux only and very pre-alpha.  Once I've added a few more features that I have in mind (e.g. multiple venvs) I'll add it to pypi and if there is sufficient interest I'd be happy to write up a PEP for getting it into the stdlib.
>>> 
>>> Does this seem like the sort of tool that would be useful in the stdlib?
>>> 
>>> Regards
>>> 
>>> David
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Python-ideas mailing list
>>> Python-ideas at python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150531/3617513e/attachment-0001.html>