[Distutils] oneget python provider?

[Vincent Povirk]

Get-Package lists locally installed packages, and Install-Packages
lists packages available from online repos.

> 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.

I'm not sure (haven't implemented installs yet), but the way my
provider currently works is that the package provider scans the
registry for python installs, runs them to get some basic information
(currently the version and site-packages location, as well as 32-bit
or 64-bit which it infers from the registry), and unless otherwise
specified Get-Package will list packages from all of them.

One can specify a python install using a -PythonVersion switch (which
is currently implemented a stupid way but will eventually do a
wildcard match, i.e. -PythonVersion 3.2 will look for 3.2.*) or by
specifying the runtime directory with -PythonLocation. I'm starting to
wonder if specifying the interpreter binary would've been better as we
could then work with e.g. IronPython without needing it to be named
python.exe.

BTW, the source code for that is here:
https://github.com/madewokherd/oneget-python

For find-package, it queries PyPI without using Python, so no version
selection is needed.

My thinking for install-package is that it will respect the
-PythonVersion and -PythonLocation switches, and will look for the
newest installed Python that is compatible with the package (assuming
the metadata has that information). If there is no compatible Python
installed (or you specified a version that isn't installed) it will
query python.org and install Python from there.

No one should have to manually install Python or Pip when
install-package is involved, if you need it then oneget should know to
install it for you.

Of course, having providers written in Python makes this a bit more
complicated, and don't have as clear an idea of how it can work.

> 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...)

I don't think we want to take that approach. We should be able to work
with the official releases from python.org at the very least.

> 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.

This is separate (unless we prefer a pip provider to be implemented in
Python) but would share some code.

Ideally, we'd want to be able to run oneget commands with -Provider
Pip without having to specify a particular install. Ideally,
get-package would query all applicable python installs, and
install-package would choose one. But for some providers, that sort of
muliplexing may not be desired.

One possible approach is for the meta-provider to look at a manifest
that has a python version requirement and call into the newest python
that meets the requirement, which then has the option to return with a
request to repeat the command on a different Python install (or a
version that isn't installed yet).

I don't think the final release will have Chocolatey enabled by
default. I'm a little unclear on what we want something like
"Install-Package python" to do out of the box, since making it work
would mean blessing some sort of central repo. We definitely want
things like "Install-Package http://python.org" to work. I don't think
the details are available yet, but this will locate the package using
<meta> tags and some xml which will eventually point to package
details including an installer (the existing msi's should work just
fine because we have an msi provider that knows how to handle those).

If you give a url to a .msi, I think that works now, and I think
find-package will also print information about them.

I could in theory write a provider that JUST gets the official python
releases from python.org (and I almost have to, so that I can install
it when needed), but I'm not sure whether it'd change the solution in
any material way. I guess you could then do "Install-Package -Provider
Python Python-3.4" but that seems a little weird.

For me personally, what's most interesting about this is distributing
Python code to people who are not Python developers, without requiring
them to install anything extra or me having to package it and all its
dependencies in some crazy Windows format. Ideally, I should be able
to package my irc client (which happens to be written in Python) in
the normal way Python software is packaged (wheels?), and if I do it
right one should be able to do "Install-Package
http://github.com/madewokherd/urk" and get it with the dependencies.

Of course, most users won't want to type commands into PowerShell to
install things either, but it's not hard to imagine transforming that
into something normal people will use.