2009/4/8 Tarek Ziadé <ziade.ta...@gmail.com>: >> Nobody seems to be attempting to collect requirements here. >> > > I do, in the wiki. I am trying to synchronize the work done at Pycon, and > in the future. I am trying to synthethize the needs there. > > http://wiki.python.org/moin/DistutilsVersionFight > http://wiki.python.org/moin/Distutils/ManifestPluginSystem > http://wiki.python.org/moin/Distutils/Metadata > http://wiki.python.org/moin/Distutils/StaticMetadata > http://wiki.python.org/moin/Distutils/StandardizeEggInfo > > What will happen in any case, is that I am going to move Distutils > forward and make decisions for Python 2.7, based on those pages that will > become PEPs at some point.
I'm aware of this, and sorry if my comments seemed to ignore this (but see below) > Some people will complain here as usual, but nevertheless. :-) > So, if you and anyone wants to help, read those wiki pages > and join, by commenting them or completing them. Hmm, I'm not sure where I'd put my requirements in that lot. So I'll try putting them here (and risk the flames :-)) Please feel free to incorporate them in the Wiki in any form you feel is appropriate. 1. (Meta-requirement) I want to be able to download a Windows installer[1] for *every* package I need. 1a. This means that the barrier for packagers building Windows installers should be as low as possible. 1b. It also means that other formats (e.g. eggs) should offer no benefit over Windows installers I'm willing to concede that not all developers can be expected to build distributions for Windows (but if they are building *anything* for Windows, it should be "obvious" that a Windows installer is the only sane choice[2]). Given that, the following requirements are what I'd want for stuff I'm expected to build myself: 2. For pure Python extensions, I can take a "standard" source tarball[3] and simply run the "standard" distutils command to build a Windows installer. 2a. I can do this on any machine, even if it has no network connection (obviously I'd get the source tarball on disk or equivalent in that case). 3. For C extensions with no dependency on external libraries, I could do the same assuming I had the "correct" C compiler present (mingw or the right version of MSVC). 4. For C extensions with external dependencies, it gets more complex - but essentially it should be "easy" for the developer to write setup.py in such a way that I can download the external dependencies in some well-defined form, configure a few file locations, then build a binary without further interaction. 4a. This is certainly possible - it's how Python itself builds 4b. This is the only case, really, where pure distutils currently fails to satisfy *my* needs. But as I'd much rather have binary builds in this case, and as I currently simply don't use packages in this category that don't have binary distributions, I don't have any specific requirements here. [1] In current terms, "Windows installer" means either bdist_wininst or bdist_msi - something that integrates with Windows "Add/Remove programs". [2] That's the problem (for me) that setuptools/easy_install has introduced. There are now packages which build Windows binaries in egg format only. Clearly there is some advantage to be had currently in distributing eggs, which is *not* present in Windows installers. That advantage is not relevant to me, so I lose out because there's no Windows installer, even though the developer clearly has the means to produce one. [3] I don't distribute packages, so I am not 100% sure what a "standard" is, but I guess sdist is what I mean here, in current terms. I hope this helps. It's intended to. I tried very hard to avoid it being an anti-setuptools comment, but I have to say that before setuptools/easy_install came along, EVERY SINGLE ONE of my requirements was satisfied by core distutils (even 4 - as the fact that building binaries in this context was difficult enough that all projects in this category supplied bdist_wininst installers as a matter of course). As a user, it feels to me as if all the benefits of setuptools (and by association, of this discussion) are for the developer, at the expense of the end user (well, end users in my situation, at least). I'd like to be proved wrong over this, of course :-) Paul. _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
