On 19 May 2015 at 13:28, Chris Barker <chris.bar...@noaa.gov> wrote:
> [...]
> So is it possible for PyPA to grow the features to mange all the python
> bits, and then have things like conda use pip inside of Anaconda, maybe? or
> SOME transition where you can add conda if and only if you need its unique
> features, and as a add-it-later-to-what-you-have solution, rather than,
> when you need R or some such, you need to
>
> * Toss out your current setup
> * Install Anaconda (or miniconda)
> * Switch from virtualenv to conda environments
> * re-install all your dependencies
>
> And for even that to work, we need a way for everything installable by pip
> to be installable within that conda environment -- which we could probably
> achieve.
>
What if instead of focusing on pip being able to install more than just
python packages, we made sure that a virtualenv was as strict subset of,
say, a conda environment? This way, going from virtualenv to, say, conda
would not be a toss-out, but an upgrade.
With all that was discussed here, ISTM it should be easy enough to make
sure that a virtualenv contains *the place* where you install the DLLs/.so
needed to make a certain pip package work, in a way that wouldn't pollute
other virtualenvs or the whole system (that'd be <venv>/lib on nix and
<venv>\Scritps or <venv>\Lib on Windows), even if pip itself is not
responsible for installing the libraries in that place.
Then, one could run something like
pip install conda-enable
Which would add a `conda` script to the virtualenv, which then could be
used to install python packages and their non Python dependencies in a way
that is pip compatible.
But what if we don't want to teach people to use anything other than pip?
Then perhaps instead of teaching pip to install non-python stuff, we could
just add some hooks to pip.
For instance, the `conda-enable` package above could install hooks that
would be called by pip whenever pip is called to install some packages. The
hook would receive the package name and its known metadata, allowing the
`conda-enable` package to go and install whatever pre-requisites it knows
about for the presented package, before pip tries to install the package
itself.
The `conda-enable` package could also add configuration to the virtualenv
telling pip which alternative indexes to use to install wheels known to be
compatible with the non-python dependencies the hook above installs.
This would give us a route that doesn't force the PYPA stack to consider
how to solve the non-python dependency issue, or even what metadata would
be required to solve it. The installed hook would need to keep a mapping of
distribution-name to non-python dependency.
In time, we could think of extending the metadata that PYPI carries to
contemplate non-python dependencies, but we could have a solution that
works even without it.
I used `conda` in the examples above, but with the hooks in place, anyone
could write their own non-python dependency resolution system.
For insance, this could be a good way for corporations to provide for the
use of standardized software for their python platforms that is not limited
to python packages, without forcing a lot of feature creep onto the PYPA
stack itself.
Cheers,
Leo
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
