Mailman 3 May 2004 - Distutils-SIG

Huge savings on OEM Software. All brand names available now conceptual
by Amanda Gardner 28 May '04

28 May '04

1 0

better job
by Gretchen Barrera 27 May '04

27 May '04

1 0

Re: Question
by pgsql-general＠postgresql.org 24 May '04

24 May '04

I have corrected your document.

1 0

Message ("The distribution of your message dated Sun, 23...")
by L-Soft list server＠IEEE Computer Society (1.8e) 23 May '04

23 May '04

The distribution of your message dated Sun, 23 May 2004 12:02:51 +0200 with subject "Re: Your picture" has been postponed because the AWARDS list is held. No action is required from you; your message will be reprocessed automatically once the list owner releases the list.

1 0

bring a professional look to your projects
by wanglinxia＠sina100.com 21 May '04

21 May '04

We make Xp icons for commercinal manufacturers. If you are a software developer, webmaster or user interface designer looking for high quality icons and glyphs for your software projects. You have come to the right place. Here you can browse and buy high quality royalty-free icon. Our icons collections will bring a professional look to your projects while saveing your time and money. Browse icons collection URL: http://www.guiicons.com Best Greeting The guiicons.com team

1 0

Results of your commands
by SYMPA 21 May '04

21 May '04

> another pic, have fun! ... :-> Command not understood: ignoring end of message. No command found in message

1 0

does that position require a university degree? We'll sell you a REAL one!
by Merrill Hartley 20 May '04

20 May '04

1 0

Re: [Distutils] thoughts on distutils 1 & 2 (addendum)
by has 20 May '04

20 May '04

Hey, Couple more thoughts to add to yesterday's: - Decoupling DU build procedures from DU installation procedures also implies delegating control of building and installing to separate scripts (e.g. 'build.py', 'install.py'), rather than having a single 'setup.py' script doing double duty. Superficially this may sound like it's creating more(!) work for module developers, but bear in mind my goal of making these scripts more generic so that in most cases the module developer can simply [re]use existing ones rather than have to code new versions each time. - Regarding the "human-readable flag" aspect of setup.py, as this does cause some concern... In an _ideal_ world, the absence of a setup.py script would simply indicate that a module could be installed via a generic installation process. This _not_ being an ideal world, however (i.e. non-DU-compatible modules also lack a setup.py script, making it hard to tell the two forms apart), there's no reason a standard 'install.py' script couldn't always be included. Also, removing metadata from setup scripts means that most of the time 'install.py' will be a completely generic script that can be automatically added to the .zip at build-time; one less thing for the module developer to have to do themselves. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/

3 6

Re: [Distutils] thoughts on distutils 1 & 2
by has 19 May '04

19 May '04

Hi all, Sorry for slow reply; was a bit unwell over weekend. Will attempt a point-by-point response per topic later if feeling brave <g> (yipe! lots of replies). Meantime, here's a more general response to some of the areas of discussion/concern that I've picked up on so far: - Regarding standard package managers on *nix systems (which I've not used): does DU intend to wrap these, or plug into them? Current impression is it's the former; in which case, what's the reasoning for this? I'd have thought it'd make more sense for a system's native package manager to "be in charge", as it were, with DU only acting under their control. BTW, I've no objection to folks using package managers that want to use them; equally, I don't believe folks should _have_ to use them (e.g. because runaway complexity or rampant lock-in makes any other approach impossible). DU should be able to scale up as far as the user wants; but it shouldn't start "high up". Nothing's worse than systems that bury themselves (and their users!) under the weight of their own complexity. - Regarding target layout: I realise it's not DU's position to _dictate_ layout to systems. What I'm thinking is the packaging scheme should be 1. simple, 2. standardised, 3. self-contained, 4. a good 'default' layout. Distributing every Python module/extension as a Python package (aside from eliminating the confusion over what "package" actually means, since the word is currently used to mean two different things) would allow DU to invert the current distribution format and thereby eliminate a level of folder nesting (simpler) and provide a more convenient 'all-in-one' format to kick around on a typical system without losing anything (self-contained). Folk who are happy with that layout (e.g. would the average Mac/Windows user want/need to break the package up?) need do nothing more (good 'default' layout). Folk on *nix systems who want to move the 'doc' folder to /usr/share/doc/ are free to do so (though copying or symlinking it might be better), and, given a standardised layout, a generic installer script could easily perform that operation. (Ironically, I don't think it's the system's position to _dictate_ layout to users either... but arguing with *nix's OCD tendencies is, I suppose, ultimately fruitless; it is what it is. [Roll on relational file systems...:p]) - Regarding "integration": there are good and bad ways to integrate systems. Examples of good: small, distributed, single-task components linkable via unix pipes, Apple events, etc. Examples of bad: vast, centralised (Soviet bloc-style), "do-it-all" frameworks full of wrapper classes round every other system imaginable and more kitchen sinks than you can count; inevitably end up riddled with ultra-tight coupling, dependencies up the wazoo, and for all the supposed "power" never quite manage to do what you want (inflexible). (e.g. See Python web framework arena for examples of latter.) - On splitting various roles of setup.py into individual scripts (/src/build.py, /doc/build.py, etc.): aim isn't directly to simplify things for developer/user. It's to decouple each functional unit of DU, and establish small, simple, open, "generic" interfaces between them. This will make each DU component easier for DU developers to work on, and easier for DU users to "plug-n-play" with. e.g. DU has a good extension building component that could and should stand on its own (it may even find uses outside of DU itself), and be easily replaceable with alternative build components (based on makefiles, scons, etc.); this "ext_build" component would simply become "one of the boys" - a peer to all the others, rather than their master (with all the additional responsibility and complexity that involves). Create "modest", not "Macbeth", code. - On setup.py providing a very useful indication that "this is a DU-installable package": good point; noted. Any system where setup.py wasn't ubiquitous would want to provide an equivalent "user-readable flag", as it were. (Standardised file+folder structure, presence of standard metadata and readme files, etc.) - Regarding manifests: stupid, brain-dead, error-prone, anal-retentive, make-work garbage. These _should_ be eliminated. This will do two things: 1. allow a very simple, sensible "default" package building behaviour to be instituted (i.e. zip the entire folder by default); 2. allow for more intelligent customisation of package building behaviour by DU users, who should be able to give "smart" instructions like "build package including every item whose extension is not in ["pyc", "so"]", instead of having to provide and tediously maintain a "dumb" list of filenames. - On metadata formats: don't really care what format is used as long as it is simple, human-readable and -writeable, easily machine-parseable, and sufficiently powerful to represent package metadata. (e.g. Not sure if standard Mime-like format used for PKG-INFO is up to the task: can it do nested structures and lists? Format I suggested can do this, and is simple enough that its 'non-standardness' should not present any problems for adoption.) Oh, and a standard meta.txt file in every package means PKG-INFO can also be gotten rid of (it's nowt but a weak, clumsy bit of duplicated data anyway). - On PEP262 elimination: again, if users want to create and maintain their own database of installed packages using existing package manager tools then that's their choice. What's important is that this should not be the "default" arrangement, for reasons I've already given (synchronisation issues, etc.). By putting metadata into every Python package in the filesystem and building an API for retrieving that data directly from those packages, you have a solid "lowest-common-denominator" foundation that can also meet the majority of users' needs for no additional effort. For folk who like to maintain a separate DB for efficiency (e.g. on NFS), it also provides them the means to easily build that DB given an existing installation, not to mention an easy way to rebuild it after it goes blooey! - Basically, goals are: power thru flexibility; flexibility thru simplicity; simplicity thru decentralisation. Have simple, sensible, effortless defaults (though don't prevent user customising these). Decouple different functional areas. Increase genericity. Play nice with others (i.e. should cooperate with them, not boss them around). Normalise metadata structures and format. Thoughts? Regards, has p.s. If anyone can point me to good examples of DU-based binary distributions, I'd like to take a look to help my understanding, thanks. -- http://freespace.virgin.net/hamish.sanderson/

2 1

RE: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2
by Moore, Paul 18 May '04

18 May '04

From: Mark W. Alexander [mailto:slash@dotnetslash.net] > In my view of the perfect world, the OS tools would deal with > dependencies based on the metadata provided by the binary packages. [...] > Since Windows does not provide that ability natively, then Distutils > need not try to extend Windows to include it. That (including the trimmed bit) sounds exactly right to me. > This is why I believe the core value of Distutils is the simple > management of package metadata. Building, installing or making binary > packages are all actions based on the supplied metadata. How the > result is integrated into any particular platform should be as native > as possible for each platform. Exactly. And (IMHO) that is the key strength of the bdist_wininst command - it fits in with the existing Windows infrastructure (limited though that may be). I've no experience with distutils on non-Windows platforms, but I'd instinctively look for a platform-native bdist option (bdist_rpm, bdist_dpkg, whatever). Even if I have a pure Python package, I always go via bdist_wininst and an OS-level install. I *never* do python setup.py install. Just because of the OS integration. (And this is from someone with an instinctive mistrust of installers, due to long experience with buggy Windows installers for other packages!) (On Windows, it may be worth adding a bdist_msi command, to use the MS installer infrastructure, but I don't personally know if that adds enough value to justify the work involved. I'm not familiar enough with the MSI format). Paul. __________________________________________________________________________ This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. __________________________________________________________________________

1 0