Impact of Windows PowerShell OneGet ?
New package manager from M$... article here http://www.neowin.net/news/windows-10-oneget-a-linux-style-package-management-framework.
It seems doubtful that M$ will eliminate .msi (their obscure, hard to configure and use, installation format), so it seems doubtful that the addition of OneGet will _force_ any changes to Python packaging.
However, it does open the question in my mind about whether there will be any _benefits_ of OneGet that would inspire helpful, useful changes to Python packaging. They speak of "trusted repositories", and the like, and it sounds like a the various *nix package managers (apt-get, et alia), but perhaps allowing multiple repositories rather than just a single source vendor repository (I'm actually not sure if *nix package managers allow multiple repositories or not, but from the way people talk about them, it always sounds like a "distribution" also provides "a repository" of additional packages).
"trusted repositories" sounds more like Perl's CPAN.
One of the links http://blogs.technet.com/b/windowsserver/archive/2014/04/03/windows-management-framework-v5-preview.aspx contains this quote: "This first version of OneGet installs and searches software from Chocolatey repositories. Support of additional repositories will come in subsequent versions."
I have no clue what a Chocolatey repository is (yet, will Google), but unknown others will come, it says... whether it is possible to write a "repository plugin" such that Perl's CPAN or Python's PyPI or other preexisting repositories can be accessed is not clear.
The relationship between PowerShell and OneGet is not clear either... is OneGet written in PowerShell, or is PowerShell just one way to invoke OneGet, or???
Just a heads up.
On Oct 29, 2014, at 3:34 PM, Glenn Linderman v+python@g.nevcal.com wrote:
New package manager from M$... article here http://www.neowin.net/news/windows-10-oneget-a-linux-style-package-management-framework.
It seems doubtful that M$ will eliminate .msi (their obscure, hard to configure and use, installation format), so it seems doubtful that the addition of OneGet will _force_ any changes to Python packaging.
However, it does open the question in my mind about whether there will be any _benefits_ of OneGet that would inspire helpful, useful changes to Python packaging. They speak of "trusted repositories", and the like, and it sounds like a the various *nix package managers (apt-get, et alia), but perhaps allowing multiple repositories rather than just a single source vendor repository (I'm actually not sure if *nix package managers allow multiple repositories or not, but from the way people talk about them, it always sounds like a "distribution" also provides "a repository" of additional packages).
"trusted repositories" sounds more like Perl's CPAN.
One of the links http://blogs.technet.com/b/windowsserver/archive/2014/04/03/windows-management-framework-v5-preview.aspx contains this quote: "This first version of OneGet installs and searches software from Chocolatey repositories. Support of additional repositories will come in subsequent versions."
I have no clue what a Chocolatey repository is (yet, will Google), but unknown others will come, it says... whether it is possible to write a "repository plugin" such that Perl's CPAN or Python's PyPI or other preexisting repositories can be accessed is not clear.
The relationship between PowerShell and OneGet is not clear either... is OneGet written in PowerShell, or is PowerShell just one way to invoke OneGet, or???
Just a heads up.
It appears to be a package manager manager. Chocolatey is one of the third party package managers available on Windows.
I also just learned that OneGet is apparently OSS and developed on github (https://github.com/OneGet/oneget https://github.com/OneGet/oneget).
--- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Thu, Oct 30, 2014 at 6:34 AM, Glenn Linderman v+python@g.nevcal.com wrote:
(I'm actually not sure if *nix package managers allow multiple repositories or not, but from the way people talk about them, it always sounds like a "distribution" also provides "a repository" of additional packages).
I'm fairly sure they all do. Certainly with apt (the Debian package manager), it's common to add additional repositories; for instance, PostgreSQL can be obtained either from the default Debian repos or from Postgres's own hosting (which usually has more versions available). A distribution will always provide a repository, and there are plenty of distros that provide only a small repo and chain to upstream for most packages - for instance AntiX has its own, and then pulls in debian.org and a few others. Adding a local-network repo is fairly straight-forward.
Most likely, OneGet won't replace pip/PyPI, any more than apt or yum does; but it may be worth having Python itself available that way. That might simply mean having someone package up Python and put it on an appropriate server, or maybe python.org could end up hosting a repo. I've no idea what "trusted" will mean; in the case of apt, any sysadmin can deem any repo to be trusted (by importing its key), but this might be more along the lines of "only curated packages" or something.
To what extent will Windows 10 users expect all their software to come via OneGet? That's the question.
ChrisA
Am 29.10.14 20:34, schrieb Glenn Linderman:
New package manager from M$... article here http://www.neowin.net/news/windows-10-oneget-a-linux-style-package-management-framework.
I've looked at it, but only by reading its code, not trying it out. Some notes.
First, what is Chocolatey? It's a PowerShell library, and a package infrastructure. A Chocolatey package is a PowerShell script that installs a piece of software on the system. The software itself comes in a different format. There are installer helpers for exe, msi and msu, Python packages (running setup.py), Ruby packages, etc. There appears to be a notion of dependencies also.
OneGet is similar; it is also a PowerShell library. It has the notion of "providers", which are classes that can make a package installed. There is the ARP provider (Add-Remove-Programs), which can report that a package is already installed. There is the MSI provider, which can install an MSI file that is already on disk. And there is the web provider which can download a file over http. They claim to include a re-implementation of Chocolatey (meaning that Chocolatey packages can be installed), however, ISTM that this only supports exe and msi packages.
I haven't seen anything resembling dependencies in OneGet.
Regards, Martin
Most likely, OneGet won't replace pip/PyPI, any more than apt or yum does; but it may be worth having Python itself available that way. That might simply mean having someone package up Python and put it on an appropriate server, or maybe python.org could end up hosting a repo.
Python is already available in Chocolatey:
https://chocolatey.org/packages/python
Given that OneGet intends to support Chocolatey as a repository, it might just work already. All python.org would have to guarantee is stable URLs for the Python msi files.
Regards, Martin
Most likely, OneGet won't replace pip/PyPI, any more than apt or yum does; but it may be worth having Python itself available that way. That might simply mean having someone package up Python and put it on an appropriate server, or maybe python.org could end up hosting a repo.
Python is already available in Chocolatey:
https://chocolatey.org/packages/python
Given that OneGet intends to support Chocolatey as a repository, it might just work already. All python.org would have to guarantee is stable URLs for the Python msi files.
I'd like it if we guarantee stable URLs anyway. The 3.5 installer will have a single flag to switch between building a full bundle (~23MB) or a tiny downloader (<500KB), but the latter option is only viable if the URLs are stable. I can also include options in the downloader for 32/64-bit versions and debug symbols, which would really reduce the choices for a user (and yes - the entire installer is still automatable and I'll write up docs to go with it for sysadmin scenarios).
(I believe that OneGet does support dependencies, since one of the intended uses is setting up dev environments. If it gets backported, I'll see about setting up a Python build environment in there, unless someone else does it first.)
Cheers, Steve
Regards, Martin
On 10/30/2014 7:30 AM, "Martin v. Löwis" wrote:
Most likely, OneGet won't replace pip/PyPI, any more than apt or yum does; but it may be worth having Python itself available that way. That might simply mean having someone package up Python and put it on an appropriate server, or maybe python.org could end up hosting a repo.
Python is already available in Chocolatey:
https://chocolatey.org/packages/python
Given that OneGet intends to support Chocolatey as a repository, it might just work already. All python.org would have to guarantee is stable URLs for the Python msi files.
It might. Thanks for that information.
Poking around the link, I discover a weirdness: the claim that the package to install 32-bit Python on 64-bit systems is different than installing the 32-bit Python on 32-bit systems. While the instructions are explicit on what to do inside the chocolatey environment for all 3 cases (the third being 64-bit install on 64-bit systems), I'm baffled as to why there is a difference, because there isn't when downloading 32-bit Python from python.org...
And there is a weird reference to chocolatey's -x86 parameter, and the explanation seems to be that chocolatey has provision for installing 32-bit or 64-bit packages on 64-bit systems, but that the way Python is included in chocolatey, that provision can't be used. Sounds very strange, like whoever set this up either didn't understand Python, or didn't understand chocolatey, or there is some limitation to the chocolatey implementation of 32-bit vs 64-bit packages.
Maybe if I understand chocolatey, this wouldn't seem so weird.
participants (5)
-
"Martin v. Löwis" -
Chris Angelico -
Donald Stufft -
Glenn Linderman -
Steve Dower