[Distutils] Distutils changes - end user requirements (Was: Deprecate MANIFEST.in)

[Paul Moore]

2009/4/9 Lennart Regebro <regebro at gmail.com>:
> 2009/4/9 Paul Moore <p.f.moore at gmail.com>:
>> Personally, I'd be happy if every package that currently distributes
>> any form of Windows binaries, distributed a Windows installer. That's
>> about the same level of coverage as existed before setuptools
>> appeared, so I don't think that's impossible to achieve. I agree that
>> expecting *everything* to have a Windows installer is unreasonable.
>
> I don't see the benefits of a windows installer in that situation. You
> are going to have a large set of python libraries, with a small subset
> of them in the Installed Software list, and the rest not. What did
> that achieve?

Sorry, I don't follow. Maybe I was unclear. One more try, and if I
still manage to confuse you, don't worry about it. It's not a major
point.

As far as I am concerned, all I need is for all the packages *I* use
to be available as Windows installers, which I'll download and
install. All of the Python packages I use are in Windows' Add/Remove
Programs.

Given that "the packages I need" isn't a particularly helpful
definition, and given that I'm a terrible dabbler and like to try out
new packages at an alarming rate (:-)), I'd like it if any package
that is distributed in a Windows binary form at all, to be in
available in Windows installer form (ie, I don't want to be forced
into a situation where, in order to use a package, I have to use an
installation method other than my preferred method).

That sounds horribly dogmatic - "everyone should work to make my life
easier" :-( It wasn't meant like that at all. For context, I'm
thinking of the days before setuptools, when everything either had a
Windows installer (bdist_wininst) or no Windows binaries at all. What
frustrates me about the current situation is seeing cases where the
developer has clearly gone to the effort to build Windows binaries,
but they aren't in a form I can (or rather, want to) use. An
egg->bdist_wininst converter would fix this issue. As would everyone
standardising on bdist_wininst (which, as per the previous message,
appears to be prefectly feasible given that bdist_wininst seems to be
a strict superset of egg...)

>> As regards your other points regarding Windows installers, I don't
>> disagree entirely. But my personal preference is to work with the
>> system packager, even if it's less functional than I'd like.
>
> But the suggestion of having packages managed from the python setup
> program is working with the system packager just as much as selecting
> what parts of Office you want is. That's what Windows users would
> expect. I don't think they, when installing Plone expect to get a
> hundred Python packages listed in the Installed Software list, as an
> extreme example. And how would it handle multiple installations into
> Python, etc.?

Ah! I see what you're getting at. If it is indeed possible to modify
the Python installer (which I believe is a MSI installer) to manage
extensions as "subpackages", then that would be a fine option, indeed.
I wasn't aware that was even possible - and I certainly am not aware
of anyone with expertise in how the standard Pytjhon binaries are
packaged having said they could take such a project on.

But if it could be done, then I'm all in favour.

> I just don't see the benefit. While having a Python package manager, I
> *can* see the benefit.
>
> But as always, I don't use Windows much nowadays, so I don't really
> care. I just want understand the thinking.

Comparing the present with package management integrated into the
Python installer, it's mainly a presumption that the latter isn't
going to happen. I was assuming the choice was between what we have
now and a standalone Python package management system which doesn't
integrate into Add/Remove programs at all. That's a much clearer
"follow the system standard" vs "roll your own" type of choice (which
is still a personal choice, of course...)

On that note, didn't ActiveState distribute their version of Python
with a package manager (PPM)? As far as I know, that was only ever
supported by ActiveState themselves, no-one else ever built PPM
packages for their extensions, and it's been quietly dropped in recent
versions (Google tells me that it vanished around Python 2.3). So that
gives some real-world evidence of how non-standard Python package
managers fare (albeit not very representative, given the limited use
of ActiveState's Python).

Paul.