We could also extend the py.exe launcher to resolve a matching Python install for a wheel and run pip to install it. Then double-clicking a wheel file would do something useful.
Having a standard UI would be better, though non-trivial. Top-posted from my Windows Phone -----Original Message----- From: "Paul Moore" <p.f.mo...@gmail.com> Sent: 8/23/2016 7:51 To: "Antoine Pitrou" <solip...@pitrou.net> Cc: "Distutils" <Distutils-Sig@python.org> Subject: Re: [Distutils] Deprecating little used file types/extensions onPyPI? On 23 August 2016 at 15:12, Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 23 Aug 2016 10:36:35 +0100 > Paul Moore <p.f.mo...@gmail.com> wrote: >> >> I don't see any sign of *anyone* working on a curated distribution for >> Windows along the lines of Linux distros or Homebrew. (Unless you >> count cross-platform stacks like conda, which IMO are a different >> scenario than "system" Python installs). > > Under Windows, there isn't much moral difference between a conda install > (really a Miniconda or Anaconda install) and a python.org Python > install. You can even install Anaconda or Miniconda system-wide. > > (Miniconda is a minimal install of Python + conda, while Anaconda is a > pretty large selection of packages in addition - though not the entire > official repo contents, and not counting community packages) Agreed - sorry, I was responding more to Nick's implication around "system" management of Python, conda already has a well-established management process, but AIUI, it's largely independent of PyPI/pip (although it interoperates with those). So in the context of Windows package managers, conda is no more relevant there than it is in relation to (say) rpm or deb. Realistically, though, I'd expect people wanting a Python stack on Windows to gravitate more and more towards distributions like Anaconda (maybe less so outside its core area of scientific use) with the remaining users sticking to the python.org builds and pip. However, I'm not that keen on continuing support for bdist_wininst and bdist_msi. I'd rather put the effort into making pip and wheels a compelling solution for such users. IMO, it already is for command line use (the more so as more hard to build packages start providing wheels). The place where pip falls down is for people who want to stick to a GUI. For those people, I believe Idle is likely to be getting an interface to pip, and I'd like to see other tools like PTVS and PyCharm get similar capabilities (if they don't have them already). That may mean exposing an interface to pip's install mechanisms that's better than "use subprocess to call pip", but we'd need some concrete use cases to work out the best form of such interfaces. On the matter of Chocolatey, it should be pretty trivial to create recipes for installing Python packages via pip. So I'd see pip+wheel as remaining the standard interface pretty much indefinitely. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig