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

[Wes Turner]

On May 31, 2015 11:20 AM, "David Townshend" <aquavitae69 at gmail.com> wrote:
>
>
>>
>> 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.

I set variables in $VIRTUAL_ENV/bin/postactivate (for Python, Go, NPM, ...)
[Virtualenvwrapper].

> 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...
>
>
> You have a point.  Maybe lack of flexibility is not actually the issue -
it's too much flexibility.  The problem that I have with virtualenv is that
it requires quite a bit of configuration and a great deal of awareness by
the user of what is going on and how things are configured.

You must set WORKON_HOME and PROJECT_HOME.

>  As stated on it's home page While there is nothing specifically wrong
with this, I usually just want a way to do something in a venv without
thinking too much about where it is or when or how to activate it.  If
you've had a look at the details of the sort of tool I'm proposing, it is
completely transparent.  Perhaps the preconfiguration is just to my own
idiosyncrasies, but if it serves its use 90% of the time then maybe that is
good enough.
>
> Some of what I'm proposing could be incorporated in to pip (i.e. better
requirements) and some could possibly be incorporated into
virtualenvwrapper (although I still think that my proposal for handling
venvs is just too different from that of virtualenvwrapper to be worth
pursuing that course), but one of the main aims is to merge it all into one
tool that manages both the venv and the requirements.

* you can install an initial set of packages with just virtualenv (a
minimal covering / only explicitly installed packages would be useful (for
pruning deprecated dependencies))
* conda-env manages requirements for conda envs (conda env export)

  * http://conda.pydata.org/docs/test-drive.html#managing-environments
  * http://conda.pydata.org/docs/env-commands.html

* I've a similar script for working with virtualenv (now venv) and/or conda
envs in gh:westurner/dotfiles/dotfiles/venv/ipython_config.py that sets FSH
paths and more commands and aliases (like cdv for cdvirtualenv) . IDK
whether this would be useful for these use cases.

So:

* [ ] ENH: pip freeze --minimum-covering
* [ ] ENH: pip freeze --explicit-only
* [ ] DOC: virtualenv for NPM'ers

>
> I'm quite sure that this proposal is not going to accepted without a
trial period on pypi, so maybe that will be the test of whether this is
useful.
>
> Is this the right place for this, or would distutils-sig be better?

PyPA: https://github.com/mitsuhiko/pipsi/issues/44#issuecomment-105961957

>
> _______________________________________________
> 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/8bde314f/attachment.html>