[Distutils] oneget python provider?

[Paul Moore]

OK, now that I've done some reading and playing with OneGet, I have a
couple of questions.

On 12 January 2015 at 05:48, Vincent Povirk <madewokherd at gmail.com> wrote:
> I've been working on a OneGet provider for Python, written in C#,
> which would basically be a frontend for PyPI/pip, but would avoid
> calling out to python for certain operations like searching PyPI, and
> would bootstrap python/pip as needed.

If someone has a couple of versions of Python installed (2.7 and 3.4
would be a typical case) how would "Install-Package requests" know
which Python installation to install requests into? The OneGet
infrastructure (much like yum, apt, etc) seems to be based around
managing "the" system Python, but on Windows the notion of having a
single special version of Python is atypical.

Unix distributions get round this by having official "python2" and
"python3" packages, and corresponding official "python2-requests" and
"python3-requests" packages. That needs to be backed by a whole
curated package stack, though, which doesn't exist for Windows
(Chocolatey ain't it, sadly...)

> However, the project lead asked at a meeting last week how useful it
> would be to be able to implement providers in other languages (by
> writing what we're calling a "meta-provider"). I could use the work
> I've done so far to make this happen for Python. So that would mean
> that any package manager written in Python could have providers that
> are also written in Python.

If I understand this correctly, it's separate from the above, and
would allow someone to write a provider in Python that could be used
to do Install-Package from (say) their internal corporate repository.
Or someone (you or the PyPA, for example) could write a provider that
installed from pip, should the question of how to handle multiple
mentioned above Pythons be resolved. Is that right? If so, then I'd be
very interested in such a thing, although more for experimenting with
alternative OneGet providers than for any Python package management
reasons. In general, I'd have thought that being able to implement
providers in multiple languages is "obviously" a good thing, as it
allows people with no PowerShell or C# background to get involved.

Having said all this, the fact that I'm the only one who's commenting
on this thread may give you an idea of how many people round here are
likely to be interested :-) I'd probably better shut up now...

Paul