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. _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
