2009/4/9 Lennart Regebro <rege...@gmail.com>: > 2009/4/9 Paul Moore <p.f.mo...@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. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig