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

[André Freitas]

+1 for this idea David.

I am using requirements.txt for managing dependencies but the NPM approach
is simpler than doing pip freeze, inspecting what are the requirements we
really use and setting up a virtualenv. If you need help with the PEP
writing I can help you.



Em dom, 31 de mai de 2015 às 09:45, Andrew Barnert via Python-ideas <
python-ideas at python.org> escreveu:

> 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:
>>
>>    1. 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...
>
>
>>    1. 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/
>>
>>
> _______________________________________________
> 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/b07df06b/attachment.html>