<p dir="ltr"><br>
On May 31, 2015 11:20 AM, "David Townshend" <<a href="mailto:aquavitae69@gmail.com">aquavitae69@gmail.com</a>> wrote:<br>
><br>
><br>
>><br>
>> 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. </p>
<p dir="ltr">I set variables in $VIRTUAL_ENV/bin/postactivate (for Python, Go, NPM, ...) [Virtualenvwrapper].</p>
<p dir="ltr">> 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...<br>
><br>
><br>
> 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.</p>
<p dir="ltr">You must set WORKON_HOME and PROJECT_HOME.</p>
<p dir="ltr">>  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.<br>
><br>
> 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.</p>
<p dir="ltr">* 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))<br>
* conda-env manages requirements for conda envs (conda env export)</p>
<p dir="ltr">  * <a href="http://conda.pydata.org/docs/test-drive.html#managing-environments">http://conda.pydata.org/docs/test-drive.html#managing-environments</a><br>
  * <a href="http://conda.pydata.org/docs/env-commands.html">http://conda.pydata.org/docs/env-commands.html</a></p>
<p dir="ltr">* 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.</p>
<p dir="ltr">So:</p>
<p dir="ltr">* [ ] ENH: pip freeze --minimum-covering<br>
* [ ] ENH: pip freeze --explicit-only<br>
* [ ] DOC: virtualenv for NPM'ers<br></p>
<p dir="ltr">><br>
> 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.<br>
><br>
> Is this the right place for this, or would distutils-sig be better?</p>
<p dir="ltr">PyPA: <a href="https://github.com/mitsuhiko/pipsi/issues/44#issuecomment-105961957">https://github.com/mitsuhiko/pipsi/issues/44#issuecomment-105961957</a><br><br></p>
<p dir="ltr">><br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
><a href="mailto:Python-ideas@python.org"> Python-ideas@python.org</a><br>
><a href="https://mail.python.org/mailman/listinfo/python-ideas"> https://mail.python.org/mailman/listinfo/python-ideas</a><br>
> Code of Conduct:<a href="http://python.org/psf/codeofconduct/"> http://python.org/psf/codeofconduct/</a><br>
</p>