[Distutils] Deprecating little used file types/extensions on PyPI?

[Paul Moore]

On 23 August 2016 at 15:12, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Tue, 23 Aug 2016 10:36:35 +0100
> Paul Moore <p.f.moore at 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