On 1 February 2014 19:29, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
On Sat, 1/2/14, Nick Coghlan <ncoghlan@gmail.com> wrote:
FWIW, installing into a venv from outside it works fine
That's what I'm saying :-)
However, it's substantially *harder* to explain to people how to use it correctly that way.
But distil installs into venvs (both PEP 405 and virtualenv) without needing to be in there. It's as simple as
distil -e path/to/venv install XYZ
So I'm not sure what you mean by "use correctly" or what exactly is hard to explain. Distil doesn't do anything special - after all, installing a distribution just means moving certain files into certain locations. If you know that you're installing into one of (a) a specific venv, or (b) user site-packages, or (c) system site-packages, then you know what the installation locations are without doing anything especially clever, don't you?
I'm talking about easing the cognitive burden on developers. The pip/virtualenv model is that once an environment is activated, developers don't need to think about it anymore - they're in that environment until they explicitly switch it off. By installing pip *into* the environment, then it is automatically affected by the same settings as all other Python components, so "pip install library" inside an activated virtual environment *just does the right thing*, and it does it in a way that doesn't require any additional custom machinery or testing. Getting a substantial usability improvement *almost for free* (since requirements.txt makes it easy to discard and rebuild virtual environments as needed, reducing the maintainability burden) is a big win. Making any installer automatically respect an activated virtual environment without installing it into that environment is no doubt *feasible*, but just installing the installer *into* the environment has the same effect with requiring any additional engineering or testing effort. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia