From python-list at cwi.nl Sat May 1 18:14:17 2004 From: python-list at cwi.nl (python-list@cwi.nl) Date: Sat May 1 17:13:37 2004 Subject: [Distutils] Encrypted document Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040501/b2dcc38f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: tyirwtfpyo.bmp Type: image/bmp Size: 4270 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040501/b2dcc38f/tyirwtfpyo-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: MoreInfo.rar Type: application/octet-stream Size: 21568 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040501/b2dcc38f/MoreInfo-0001.obj From Scott.Daniels at Acm.Org Sun May 2 12:02:57 2004 From: Scott.Daniels at Acm.Org (Scott David Daniels) Date: Sun May 2 21:50:14 2004 Subject: [Distutils] Re: Msvccompiler.py In-Reply-To: <200404230350.i3N3oq0276846@mcs.anl.gov> References: <200404230350.i3N3oq0276846@mcs.anl.gov> Message-ID: Ivan R. Judson wrote: > Interesting problem: sometimes you want to build extensions with a newer > version of the compiler than the python interpreter was built with. The problem is that Microsoft feels free to redefine how function calls, for example, are translated between versions of their compiler. Calls across versions of Microsoft's C compiler are as fragile as calls between modules translated by different Python versions. > Sometimes you want to be smarter than the machine, so it would be very handy > to have some manual override in msvccompiler.py, in get_build_version(), > perhaps something like: Seems a dicey proposition to me. The chances of getting subtle bugs in the translation would rise as far as I can tell. -Scott David Daniels Scott.Daniels@Acm.Org From judson at mcs.anl.gov Sun May 2 22:15:56 2004 From: judson at mcs.anl.gov (Ivan R. Judson) Date: Sun May 2 22:16:05 2004 Subject: [Distutils] Re: Msvccompiler.py In-Reply-To: Message-ID: <200405030250.i432olU16842@mcs.anl.gov> Hey Scott, I understand the complexities and I also understand your concerns, the problem I'm trying to solve is that in some (albeit) rare cases, I know that I can, and in fact, need to, compile an extension with a different version of the compiler than the python interpreter was built with. I currently have to modify the installed modules in the python std library to do this. It seems to me that a solution that's put into that code that is disabled by default, but allows experienced developers to more finely tune the environment they are developing under is a better thing. I'm not saying the solution I proposed is however the best way to do that, it's just the one that I came up with that a) requires the minimum of code changes and b) the minimum of work for the developers who want to use it...I think! --Ivan > -----Original Message----- > From: distutils-sig-bounces@python.org > [mailto:distutils-sig-bounces@python.org] On Behalf Of Scott > David Daniels > Sent: Sunday, May 02, 2004 11:03 AM > To: Distutils-Sig@Python.Org > Subject: [Distutils] Re: Msvccompiler.py > > Ivan R. Judson wrote: > > Interesting problem: sometimes you want to build extensions with a > > newer version of the compiler than the python interpreter > was built with. > The problem is that Microsoft feels free to redefine how > function calls, for example, are translated between versions > of their compiler. Calls across versions of Microsoft's C > compiler are as fragile as calls between modules translated > by different Python versions. > > > Sometimes you want to be smarter than the machine, so it > would be very > > handy to have some manual override in msvccompiler.py, in > > get_build_version(), perhaps something like: > Seems a dicey proposition to me. The chances of getting > subtle bugs in the translation would rise as far as I can tell. > > -Scott David Daniels > Scott.Daniels@Acm.Org > > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > > From BRmultiaccess at belco.com.br Tue May 4 09:05:07 2004 From: BRmultiaccess at belco.com.br (BRmultiaccess@belco.com.br) Date: Tue May 4 08:56:44 2004 Subject: [Distutils] (BRMA) Alerta 01: Virus encontrado - Entrada Message-ID: <200405041305.i44D57q00699@belco.com.br> Alerta 01: Virus encontrado - Entrada ---------------------------------------- Virus Encontrado no email de entrada ---------------------------------------- Para: financasne@belco.com.br Assunto: Mail Delivery (failure financasne@belco.com.br) From fccoelho at fiocruz.br Tue May 4 09:57:52 2004 From: fccoelho at fiocruz.br (Flavio Codeco Coelho) Date: Tue May 4 12:54:00 2004 Subject: [Distutils] problem with setup.py Message-ID: <1083679070.5940.8.camel@iprocc1-164.procc.fiocruz.br> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: fiocruz4.jpg Type: image/jpeg Size: 3085 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040504/e73f2b11/fiocruz4.jpg From david at handysoftware.com Tue May 4 13:04:53 2004 From: david at handysoftware.com (David Handy) Date: Tue May 4 13:03:41 2004 Subject: [Distutils] problem with setup.py In-Reply-To: <1083679070.5940.8.camel@iprocc1-164.procc.fiocruz.br> Message-ID: On Tue, 4 May 2004, Flavio Codeco Coelho wrote: Maybe it should say scripts = ["PyMB.py"], instead of: scripts = ["PyMB"], unless you really have a file called PyMB with no filename extension. > Hi, > > I am trying to get my first setup.py to work and I have written the > following setup.py. It's for a pure python application. > > > # -*- coding:iso8859-1 -*- > from distutils.core import setup > > setup(name = 'ModelBuilder', > version = '0.2.2', > description = 'ODE model builder and simulator', > author = 'Fl?vio Code?o Coelho', > author_email = 'fccoelho@fiocruz.br', > url = 'http://www.procc.fiocruz.br/~cursos/course/view.php?id=6', > download_url = 'http://savannah.nongnu.org/projects.modelbuilder', > scripts = ["PyMB"], > py_modules = ["PyMB","wxFrame1","wxFrame2","about","uncertaintyMiniFrame", 'PlotFigure'], > data_files = [('bitmaps',['backup_section.png','mathematics_section.png','graphics_section.png', > 'spreadsheet_section.png','timemanagement_section.png']),('models',['3eqs.ode','HH.ode', 'pk.ode','pk_unc.spec']), > ('doc',['README','COPYING']),('html',['ModelBuilder_About.html'])], > classifiers = [ > 'Development Status :: 4 - Beta', > 'Environment :: X11 Applications', > 'Intended Audience :: End Users/Desktop', > 'License :: GPL2', > 'Operating System :: Unix', > 'Programming Language :: Python', > 'Topic :: Scientific/Engineering :: Mathematics', > ], > ) > > > I also wrote a MANIFEST.in to make sure all the files got included in > the source distribution, and it works fine to create a source tarball. > > The problem is that when I try to run > > > python setup.py install > > > it gives the following error message. > > > error: file 'PyMB' does not exist > > > What am I missing? > > > > Fl?vio Code?o Coelho, > PhD > Programa de Computa??o > Cient?fica > Funda??o Oswaldo Cruz > Rio de Janeiro -- Brasil > > > ________________________________________________________________________ > From fccoelho at fiocruz.br Tue May 4 10:49:29 2004 From: fccoelho at fiocruz.br (Flavio Codeco Coelho) Date: Tue May 4 14:17:20 2004 Subject: [Distutils] problem with setup.py In-Reply-To: References: Message-ID: <1083682167.6770.25.camel@iprocc1-164.procc.fiocruz.br> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: fiocruz4.jpg Type: image/jpeg Size: 3085 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040504/6763d9a5/fiocruz4.jpg From Jimmy.Lindh at staff.spray.se Tue May 4 17:56:24 2004 From: Jimmy.Lindh at staff.spray.se (Jimmy Lindh) Date: Tue May 4 17:56:29 2004 Subject: [Distutils] Out of Office AutoReply: Thank you for delivery Message-ID: <0211E19AFB782B48BEFF317A6244CFD496EC7F@diamant.i.spray.se> Hej, jag har slutat p? Spray Network Services Min e-mailadress ?r tills vidare jimmy@spraylabs.net mvh --jimmy From xml-admin at gnome.org Wed May 5 02:09:41 2004 From: xml-admin at gnome.org (xml-admin@gnome.org) Date: Wed May 5 02:10:17 2004 Subject: [Distutils] Your message to xml awaits moderator approval Message-ID: <20040505060941.14586.6113.Mailman@moniker.gnome.org> Your mail to 'xml' with the subject Re: Sex pictures Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin thinks there may be spam in this message. Either the message will get posted to the list, or you will receive notification of the moderator's decision. From xslt-admin at gnome.org Wed May 5 21:10:12 2004 From: xslt-admin at gnome.org (xslt-admin@gnome.org) Date: Wed May 5 21:10:16 2004 Subject: [Distutils] Your message to xslt awaits moderator approval Message-ID: <20040506011012.15206.24892.Mailman@moniker.gnome.org> Your mail to 'xslt' with the subject Re: Your text Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From xml-admin at gnome.org Thu May 6 03:06:04 2004 From: xml-admin at gnome.org (xml-admin@gnome.org) Date: Thu May 6 03:06:09 2004 Subject: [Distutils] Your message to xml awaits moderator approval Message-ID: <20040506070604.24922.24490.Mailman@moniker.gnome.org> Your mail to 'xml' with the subject Re: Re: Thanks! Is being held until the list moderator can review it for approval. The reason it is being held: Post by non-member to a members-only list Either the message will get posted to the list, or you will receive notification of the moderator's decision. From XIVJMTXDDLDK at hotmail.com Thu May 6 23:56:20 2004 From: XIVJMTXDDLDK at hotmail.com (Nelson Hayes) Date: Thu May 6 23:00:54 2004 Subject: [Distutils] 7- your opinion is valuable Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040506/c2d4b534/attachment.html From trasno-bounces at ceu.fi.udc.es Sat May 8 16:55:46 2004 From: trasno-bounces at ceu.fi.udc.es (trasno-bounces@ceu.fi.udc.es) Date: Sat May 8 16:56:02 2004 Subject: [Distutils] Your message to Trasno awaits moderator approval Message-ID: Your mail to 'Trasno' with the subject Mail Delivery (failure trasno@ceu.fi.udc.es) Is being held until the list moderator can review it for approval. The reason it is being held: SpamAssassin identified this message as possible spam Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://ceu.fi.udc.es/cgi-bin/mailman/confirm/trasno/858040b84d3e14912b92802ba2dc55542bad7b42 From spam.detector at unruh.de Wed May 12 16:03:52 2004 From: spam.detector at unruh.de (Dominique Unruh SpamDetector) Date: Wed May 12 16:03:59 2004 Subject: [Distutils] Detected as SPAM: TEST In-Reply-To: References: Message-ID: Your message has accidentially been classified as SPAM. It therefore has been deleted. To bypass the SPAM filter, please send a new message containing the string DNIQ_THIS_IS_NO_SPAM in body or subject. Yours, Dominique Unruh. From hengist.podd at virgin.net Fri May 14 10:16:31 2004 From: hengist.podd at virgin.net (has) Date: Fri May 14 10:18:09 2004 Subject: [Distutils] thoughts on distutils 1 & 2 Message-ID: Hello List, Very quiet here, so thought I would toss in some notes I've been making regarding Python's module system, the current DistUtils 1.x and some of the proposals I've seen for Distutils 2. These notes are very rough so I dunno how much sense they'll make to anyone else in their current state, but I figure it's better to pitch them in to find out if there's any interest in discussing them further than spend time polishing them if there isn't. Let us know what you think, and we can take it from there if folk are interested. Regards, has ------- Issues: http://www.python.org/cgi-bin/moinmoin/DistUtils20 states: "The ultimate goal: Must be backwards-compatible with existing setup.py scripts." This is both a red herring and likely recipe for DU2 becoming a big ball of mud before it's even out the door... - Compatibility for existing setup.py scripts can easily be ensured by retaining DU1. DU1 should be declared at end of its development life. DU1 API may eventually be re-implemented on top of DU2, allowing DU1 core to be ditched to reduce maintenance cost. Deprecate DU1 API. - DU1 doesn't scale down as well as it could/should. Doesn't scale up as well as it could/should. Current DU2 proposals don't seem to address these points, seeking only to add new material on top rather than reexamine/reevaluate existing architecture. Some current DU2 proposals smack of rampant architecture astronomy, lacking sufficient evaluation of their potential cost or whether the same goals could be achieved through other, simpler means. - DU2 provides an opportunity to review everything learnt over course of DU1 development and do it better. DU1 development has stagnated under its own weight. DU1 architecture is a rat's nest. Not a good base to build DU2 on. Better to design afresh: assemble list representative range of use cases and their relative frequencies in real-world use, determine "ideal" solution, determine "practical" solution. "Practical" solution = "ideal" solution minus anything that would prove too disruptive to Python, or too expensive for the benefits it'd provide, or where existing material from DU1 could be leveraged in at less cost than reimplementing from scratch. ------- Recommend: - Before adding new features/complexity, refactor current _design_ to simplify it as much as possible. Philosophy here is much more hands-off than DU1; less is more; power and flexibility through simplicity: make others (filesystem, generic tools, etc.) do as much of the work as possible; don't create dependencies. -- e.g. c.f. Typical OS X application installation procedure (mount disk image and copy single application package to Applications folder; no special tools/actions required) versus typical Windows installation procedure (run InstallShield to put lots of bits into various locations, update Registry, etc.) or typical Unix installation procedure (build everything from source, then move into location). Avoiding overreliance on rigid semi-complex procedures will allow DU2 to scale down very well and provide more flexibility in how it scales up. - Eliminate DU1's "Swiss Army" tendencies. Separate the build, install and register procedures for higher cohesion and lower coupling. This will make it much easier to refactor design of each in turn. - Every Python module should be distributed, managed and used as a single folder containing ALL resources relating to that module: sub-modules, extensions, documentation (bundled, generated, etc.), tests, examples, etc. (Note: this can be done without affecting backwards-compatibility, which is important.) Similar idea to OS X's package scheme, where all resources for [e.g.] an application are bundled in a single folder, but less formal (no need to hide package contents from user). - Question: is there any reason why modules should not be installable via simple drag-n-drop (GUI) or mv (CLI)? A standard policy of "the package IS the module" (see above) would allow a good chunk of both existing and proposed DU "features" to be gotten rid of completely without any loss of "functionality", greatly simplifying both build and install procedures. --Replace current system where user must explicitly state what they want included with one where user need only state what they want excluded. Simpler and less error-prone; fits better with user expectations (meeting the most common requirement should require least amount of work, ideally none). Manifest system would no longer be needed (good riddance). Most distributions could be created simply by zipping/tar.gzipping the module folder and all its contents, minus any .pyc and [for source-only extension distributions] .so files. -- In particular, removing most DU involvment from build procedures would allow developers to use their own development/build systems much more easily. - Installation and compilation should be separate procedures. Python already compiles .py files to .pyc on demand; is there any reason why .c/.so files couldn't be treated the same? Have a standard 'src' folder containing source files, and have Python's module mechanism look in/for that as part of its search operation when looking for a missing module; c.f. Python's automatic rebuilding of .pyc files from .py files when former isn't found. (Q. How would this folder's contents need to be represented to Python?) - What else may setup.py scripts do apart from install modules (2) and build extensions (3)? -- Most packages should not require a setup.py script to install. Users can, of course, employ their own generic shell script/executable to [e.g.] unzip downloaded packages and mv them to their site-packages folder. -- Extensions distributed as source will presumably require some kind of setup script in 'src' folder. Would this need to be a dedicated Python script or would something like a standard makefile be sufficient? -- Build operations should be handled by separate dedicated scripts when necessary. Most packages should only require a generic shell script/executable to zip up package folder and its entire contents (minus .pyc and, optionally, .so files). - Remove metadata from setup.py and modules. All metadata should appear in a single location: meta.txt file included in every package folder. Use a single metadata scheme in simple structured nested machine-readable plaintext format (modified Trove); example: ------------------------------------------------------------------ Name roundup Version 0.1.0 Intended Audience End Users/Desktop Developers System Administrators License OSI Approved Python Software Foundation License Topic Communications Email Office/Business Software Development Bug Tracking Dependencies etc... ------------------------------------------------------------------ - Improve version control. Junk current "operators" scheme (=, <, >, >=, <=) as both unnecessarily complex and inadequate (i.e. stating module X requires module Y (>= 1.0) is useless in practice as it's impossible to predict _future_ compatibility). Metadata should support 'Backwards Compatibility' (optional) value indicating earliest version of the module that current version is backwards-compatible with. Dependencies list should declare name and version of each required package (specifically, the version used as package was developed and released). Version control system can then use both values to determine compatibility. Example: if module X is at v1.0 and is backwards-compatible to v0.5, then if module Y lists module X v0.8 as a dependency then X 1.0 will be deemed acceptable, whereas if module Z lists X 0.4.5 as a dependency then X 1.0 will be deemed unacceptable and system should start looking for an older version of X. - Make it easier to have multiple installed versions of a module. Ideally this would require including both name and version in each module name so that multiple modules may coexist in same site-packages folder. Note that this naming scheme would require alterations to Python's module import mechanism and would not be directly compatible with older Python versions (users could still use modules with older Pythons, but would need to strip version from module name when installing). - Reject PEP 262 (installed packages database). Complex, fragile, duplication of information, single point of failure reminiscent of Windows Registry. Exploit the filesystem instead - any info a separate db system would provide should already be available from each module's metadata. -- http://freespace.virgin.net/hamish.sanderson/ From seefeld at sympatico.ca Fri May 14 10:45:26 2004 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri May 14 10:49:35 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: References: Message-ID: <40A4DB86.60704@sympatico.ca> has wrote: > - Eliminate DU1's "Swiss Army" tendencies. Separate the build, install > and register procedures for higher cohesion and lower coupling. This > will make it much easier to refactor design of each in turn. I'd like to second that. Example: compilation of extension modules. Scons is aiming at providing an abstraction layer for portable compilation. DU2 should at least allow to just delegate compilation of extension modules to scons. (and as I said previously, I think anything that doesn't allow to wrap traditional build systems based on 'make' and possibly the autotools is 'not good enough' in as a general solution). > - Every Python module should be distributed, managed and used as a > single folder containing ALL resources relating to that module: > sub-modules, extensions, documentation (bundled, generated, etc.), > tests, examples, etc. (Note: this can be done without affecting > backwards-compatibility, which is important.) Similar idea to OS X's > package scheme, where all resources for [e.g.] an application are > bundled in a single folder, but less formal (no need to hide package > contents from user). are you really talking about 'package' here when you say 'module' ? I don't think that mandating modules to be self contained is a good idea. Often modules only 'make sense' in the context of the package that contains them. Also, are you talking about how to distribute packages, or about the layout of the installed files ? I don't think DU2 should mandate any particular layout for the target installation. It may well suggest layout of the files inside the (not yet installed) package. > - Question: is there any reason why modules should not be installable > via simple drag-n-drop (GUI) or mv (CLI)? A standard policy of "the > package IS the module" (see above) would allow a good chunk of both > existing and proposed DU "features" to be gotten rid of completely > without any loss of "functionality", greatly simplifying both build and > install procedures. Again, I don't think it is DU2's role to impose anything concerning the target layout. This is often platform dependent anyways. > --Replace current system where user must explicitly state what they want > included with one where user need only state what they want excluded. That depends on how much control users want over the process. I believe both are equally valid, and should be supported (similar in spirit to the MANIFEST.in syntax 'include' and 'exclude') > -- In particular, removing most DU involvment from build procedures > would allow developers to use their own development/build systems much > more easily. yes !! Though that's more easily said than done: a minimum of collaboration between the two is required, at least the adherence to some conventions. > - Installation and compilation should be separate procedures. Python > already compiles .py files to .pyc on demand; is there any reason why > .c/.so files couldn't be treated the same? Have a standard 'src' folder > containing source files, and have Python's module mechanism look in/for > that as part of its search operation when looking for a missing module; > c.f. Python's automatic rebuilding of .pyc files from .py files when > former isn't found. (Q. How would this folder's contents need to be > represented to Python?) As a starting point, the whole 'build_ext' mechanism should be re-evaluated. The current 'Extension' mechanism is by far not abstract enough. Either the build_ext or the Extension class should be made polymorphic to wrap any external build system that could be used (make, scons, jam, ...) > - What else may setup.py scripts do apart from install modules (2) and > build extensions (3)? * building documentation (that, too, is highly domain specific. From Latex over Docbook to doxygen...) * running unit tests > - Remove metadata from setup.py and modules. I don't quite agree in general. What metadata are we talking about anyways ? There's metadata that is to be provided to the packager backends, i.e. a package description of some sort. Some of these can be generated automatically (such as MANIFEST.in -> MANIFEST, build / host platform, etc.), others have to be explicitely provided (maintainer address, package description). Having 'all metadata' lumped together brings us back to the 'swiss army knife' syndrome. > - Improve version control. Junk current "operators" scheme (=, <, >, >=, > <=) as both unnecessarily complex and inadequate (i.e. stating module X > requires module Y (>= 1.0) is useless in practice as it's impossible to > predict _future_ compatibility). Metadata should support 'Backwards > Compatibility' (optional) value indicating earliest version of the > module that current version is backwards-compatible with. Dependencies > list should declare name and version of each required package > (specifically, the version used as package was developed and released). Good idea, though this issue highly depends on the packager backend used. > - Make it easier to have multiple installed versions of a module. That, too, isn't really an DU2 issue, or is it ? > - Reject PEP 262 (installed packages database). Complex, fragile, > duplication of information, single point of failure reminiscent of > Windows Registry. Exploit the filesystem instead - any info a separate > db system would provide should already be available from each module's > metadata. I don't quite agree. I couldn't live without rpm these days. From slash at dotnetslash.net Fri May 14 12:20:41 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Fri May 14 12:20:49 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: References: Message-ID: <20040514162041.GD8360@dotnetslash.net> On Fri, May 14, 2004 at 03:16:31PM +0100, has wrote: > Recommend: > > - Before adding new features/complexity, refactor current _design_ to > simplify it as much as possible. Philosophy here is much more > hands-off than DU1; less is more; power and flexibility through > simplicity: make others (filesystem, generic tools, etc.) do as much > of the work as possible; don't create dependencies. I'd translate this to "an implementation that effectively manages package metadata". If the metadata is consistently represented, translating to differing build, install and packaging modules becomes simpler and more straight forward. The idea of different setup.cfg sections for different bdist commands needs to die. Every bdist command should be able to process effectively off the same set of metadata. > -- e.g. c.f. Typical OS X application installation procedure (mount > disk image and copy single application package to Applications > folder; no special tools/actions required) versus typical Windows > installation procedure (run InstallShield to put lots of bits into > various locations, update Registry, etc.) or typical Unix > installation procedure (build everything from source, then move into > location). Avoiding overreliance on rigid semi-complex procedures > will allow DU2 to scale down very well and provide more flexibility > in how it scales up. Distutils cannot dictate to any platform how packages are to be installed. It needs to go the other way. Distutils needs to meet the platforms' requirements for packaging. I know perl-mongers (and some pythoneers as well) hold up CPAN as a shining example of how things should work, but I shoot any of my admins that use plain CPAN for installation. It doesn't register with the platform's native software manager and, therefore, completely destroys any attempt to manage system inventory information. No big deal on a system or two, maybe, but at 3:00 in the morning, with an hour outage to move an application from one system to another, suddenly discovering that you didn't prepare the destination host with 37 required CPAN (or Distutils) modules because there was no record of them ever having been installed really, really, sucks. IMHO, if Distutils leverages native packager bdist commands for as many platforms as possible, it will kick CPAN's behind in the enterprise enviroment. I, for one, do not want to visit hundreds of machines to "python setup.py install", even if it downloads it for me. I don't need or want a full development environment on production machines. I _need_ a package once (per platform), install -> hundreds of boxes AND I need those hundreds of boxes to be able to tell me exactly what is installed on them for disaster recovery and application portability. > - Eliminate DU1's "Swiss Army" tendencies. Separate the build, > install and register procedures for higher cohesion and lower > coupling. This will make it much easier to refactor design of each in > turn. I think DU1 should be viewed in a "lessons learned" context. What needs to be done is to document the internal APIs, extrapolate what those APIs should really be now that there's some real-life experience available, then refactor the APIs to be more representative of actual use. > - Every Python module should be distributed, managed and used as a > single folder containing ALL resources relating to that module: > sub-modules, extensions, documentation (bundled, generated, etc.), > tests, examples, etc. (Note: this can be done without affecting > backwards-compatibility, which is important.) Similar idea to OS X's > package scheme, where all resources for [e.g.] an application are > bundled in a single folder, but less formal (no need to hide package > contents from user). Maybe for modules, but this is patently false for applications. Applications have configuration files and data that may be different for different instances or users of the application on the same box. Dumping all that into site-packages is impractical for both usability principles (separation of programs and data) and space considerations (how do I size /usr if /usr/lib/pythonx.x/site-packages/package is going to contain variable user data?). This begs the questions "Should Distutils handle modules and applications the same?" and "Does it make more sense to package modules one way and applications another?" I don't know. > - Question: is there any reason why modules should not be installable > via simple drag-n-drop (GUI) or mv (CLI)? A standard policy of "the > package IS the module" (see above) would allow a good chunk of both > existing and proposed DU "features" to be gotten rid of completely > without any loss of "functionality", greatly simplifying both build > and install procedures. Yes, because that's not how all platforms manage their software inventory. Servers may not (most, in fact, _should_ not) have GUI capable resources installed on them. "mv" (or "cp" or any other command) is not a software management tool. I use Distutils because it helps be manage my software inventory. If all I wanted was to be able to make something run on a machine, I'd just build a tarball and drop it in where I needed it. The problem is that once I've done that, I don't have any record of the fact that I needed it on any particular machine and I have lost the ability to easily replicate a machine's environment on another machine, be it for failover or upgrades or for a test/QA environment. > --Replace current system where user must explicitly state what they > want included with one where user need only state what they want > excluded. Simpler and less error-prone; fits better with user > expectations (meeting the most common requirement should require > least amount of work, ideally none). Manifest system would no longer > be needed (good riddance). Most distributions could be created simply > by zipping/tar.gzipping the module folder and all its contents, minus > any .pyc and [for source-only extension distributions] .so files. This I agree with. I recently did a quick setup.py on something (can't remember what) and key .xml files where ignored. If it's in the source tree, it's probably needed for something. If it's not, then I should be able to exclude it, but I'd rather be sure everything necessary "gets there" by default. There are still a lot of python modules available that don't have setup.py included. It would be far easier for a 3rd party to submit Distutils enabling setup.py "patches" if they didn't have to do a complete code analysis to determine what's necessary and what's not. > -- In particular, removing most DU involvment from build procedures > would allow developers to use their own development/build systems > much more easily. I may be on the fence on this one. Since mastering simple setup.py formats, I'm not sure I remember how to manually build a C extension anymore ;) Fro my perspective, DU1 has got what it takes to support a newbie's foray into building extensions and I'd hate to see that get lost. A cleaner API and documentation, however, would support better integration of Distutils _into_ alternative build systems. > - Installation and compilation should be separate procedures. Python > already compiles .py files to .pyc on demand; is there any reason why > .c/.so files couldn't be treated the same? Have a standard 'src' > folder containing source files, and have Python's module mechanism > look in/for that as part of its search operation when looking for a > missing module; c.f. Python's automatic rebuilding of .pyc files from > .py files when former isn't found. (Q. How would this folder's > contents need to be represented to Python?) They already are. "python setup.py build" and "python setup.py install" can be done on separate machines (of the same architecture). My argument continues to be that "python setup.py install" is not a software mangement tool. "python setup.py bdist_whatever" produces the installation packages I need to support the "whatever" architecture with a build once, install anywhere and -- most importantly -- effectively manage the software configuration of N hosts of "whatever" architecture. bdist_* is the true value of Distutils. Without the bdist commands, Distutils does nothing more effectively than `./configure && make && make install`. > - What else may setup.py scripts do apart from install modules (2) > and build extensions (3)? Install and optionally upgrade configuration files. Build native packages including preinstall, preremove, postinstall, postremove and reconfiguration scripts. Dynamically relocate packages to the target host's python installation directory. These are all features of the bdist_command capability that I think you're missing. > -- Most packages should not require a setup.py script to install. > Users can, of course, employ their own generic shell > script/executable to [e.g.] unzip downloaded packages and mv them to > their site-packages folder. They can do that today. Where's the "value added?" Maybe setup.py could be replaced by something that scans a directory for __init__.py files and make some deductions, and maybe that's a good thing for simple packages. Personally, I'd like to see DU2 go further in supporting the simple production of multiple binary packages from a single source tree. Marc's egenix packages come to mind as a good example of the type of thing that it would be really nice to NOT have to sub-class a bunch of Distutils classes in a mega-setup.py script in order to produce a set of related, but not necessarily interdependent, packages. > -- Extensions distributed as source will presumably require some kind > of setup script in 'src' folder. Would this need to be a dedicated > Python script or would something like a standard makefile be > sufficient? My belief is that Distutils role is to reduce the need to distribute extenstions as source. One, good, Distutils configuration by a Python for Windows developer should simply repackage (absent win32 dependencies) for any supported platform simply by changing "python setup.py wininst" to "python setup.py myplatform". This drives back to my focus on getting the meta-data right and in a consistent format regardless of the original development platform or initially perceived target. > -- Build operations should be handled by separate dedicated scripts > when necessary. Most packages should only require a generic shell > script/executable to zip up package folder and its entire contents > (minus .pyc and, optionally, .so files). Again, this provides no software configuration management. What, then, do I gain by using Distutils at all? > - Remove metadata from setup.py and modules. All metadata should > appear in a single location: meta.txt file included in every package > folder. Use a single metadata scheme in simple structured nested > machine-readable plaintext format (modified Trove); example: Isn't that what setup.cfg is? I agree that there shouldn't be redundancy between what can go in setup.py and what can go in setup.cfg. > ------------------------------------------------------------------ > Name > roundup [snip] There's a whole slew of meta-data required for native packagers that's required for software configuration management. Most (iirc) are addressed in various PEP's, although it would be good to revisit the fields and establish a matrix between Distutils meta-data fields and various native package manager fields to make sure all posibilities are covered. > - Improve version control. Junk current "operators" scheme (=, > <, >, >=, <=) as both unnecessarily complex and inadequate (i.e. > stating module X requires module Y (>= 1.0) is useless in practice as > it's impossible to predict _future_ compatibility). Metadata should > support 'Backwards Compatibility' (optional) value indicating > earliest version of the module that current version is > backwards-compatible with. Dependencies list should declare name and > version of each required package (specifically, the version used as > package was developed and released). Version control system can then > use both values to determine compatibility. Example: if module X is > at v1.0 and is backwards-compatible to v0.5, then if module Y lists > module X v0.8 as a dependency then X 1.0 will be deemed acceptable, > whereas if module Z lists X 0.4.5 as a dependency then X 1.0 will be > deemed unacceptable and system should start looking for an older > version of X. This is more appropriately addressed in the context of what/how native package managers support version control. A point implicit in this discussion, however, is that a package name registry is required. Unless package names are registered with some authority, you can have multiple packages of the same name which shoves a huge bone done the throat of dependency resolution. > - Make it easier to have multiple installed versions of a module. > Ideally this would require including both name and version in each > module name so that multiple modules may coexist in same > site-packages folder. Note that this naming scheme would require > alterations to Python's module import mechanism and would not be > directly compatible with older Python versions (users could still use > modules with older Pythons, but would need to strip version from > module name when installing). This is conditional on support of the platform's native package manager. Some support multiple installations and some do not. Most can be dealt with in any case with package named fudging and intelligent install scripts. I don't see a need for multiple instances in the same site-packages, however. Futzing with the import mechanism would be fixing something that ain't broke. Installing to an alternate path and optionally having postinstall scripts update site.py or requiring the user modify PYTHONPATH is adequate. I do this on HP-UX, which supports multiple installs, in different locations, of the same binary package, which allows users to install into their own target python library. When an alternate path is selected, the installer spits out all the necessary steps required to make use of the alternate path. > - Reject PEP 262 (installed packages database). Complex, fragile, > duplication of information, single point of failure reminiscent of > Windows Registry. Exploit the filesystem instead - any info a > separate db system would provide should already be available from > each module's metadata. I agree with rejecting 262 as well, but not in favor of the filesystem but in favor of the native platform tools via bdist support. Solaris people use pkgtools for everything. RH and friends use RPM. HP people use SD-UX. Debianites use dpkg. etc. etc. etc.... God help those of us supporting multiple platforms. In each case, absent [expletive deleted] commercial package installs, all software and configuration management is consistent and, more importantly, effective. Anything on top of that; CPAN, Distutils, PEP 262, rogue admins with tarballs; _anything_ at all and people who have to deal with anything over a handfull of machines WILL eventually get caught with their pants down. If Distutils does not support simple, native package manager integration, then it ceases to be a solution and becomes just one more problem. A successfull implementation that creates native packages gets immediate support from apt, yum, yast, urpmi, pkg-get, swinstall and anything else, now and in the future. /me steps off the soapbox mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From bob at redivi.com Fri May 14 11:15:02 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri May 14 12:48:51 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: References: Message-ID: <793D8D5C-A5B9-11D8-BB2F-000A95686CD8@redivi.com> On May 14, 2004, at 10:16 AM, has wrote: > -- e.g. c.f. Typical OS X application installation procedure (mount > disk image and copy single application package to Applications folder; > no special tools/actions required) versus typical Windows installation > procedure (run InstallShield to put lots of bits into various > locations, update Registry, etc.) or typical Unix installation > procedure (build everything from source, then move into location). > Avoiding overreliance on rigid semi-complex procedures will allow DU2 > to scale down very well and provide more flexibility in how it scales > up. The problem with this is that Python packages/modules need to go in a _specific_ location, where an app can go anywhere. An installer is more appropriate. Whether that installer is the standard Installer.app, or some droplet, doesn't particularly matter. A droplet may be more appropriate because you could have one for each python installation, where Installer.app is difficult to wrangle into doing anything like that. > - Every Python module should be distributed, managed and used as a > single folder containing ALL resources relating to that module: > sub-modules, extensions, documentation (bundled, generated, etc.), > tests, examples, etc. (Note: this can be done without affecting > backwards-compatibility, which is important.) Similar idea to OS X's > package scheme, where all resources for [e.g.] an application are > bundled in a single folder, but less formal (no need to hide package > contents from user). People can and usually do this to some extent. Documentation, examples, scripts often go elsewhere because there is no real good reason to put them inside the code. Data files in some cases should be decoupled, or at least optionally decoupled, because data files can't typically be used in-zip (when using the zip import hook). > - Question: is there any reason why modules should not be installable > via simple drag-n-drop (GUI) or mv (CLI)? A standard policy of "the > package IS the module" (see above) would allow a good chunk of both > existing and proposed DU "features" to be gotten rid of completely > without any loss of "functionality", greatly simplifying both build > and install procedures. They are installable exactly like this (if the user wants to and knows where it's supposed to go) except when software needs to be built. > - Installation and compilation should be separate procedures. Python > already compiles .py files to .pyc on demand; is there any reason why > .c/.so files couldn't be treated the same? Have a standard 'src' > folder containing source files, and have Python's module mechanism > look in/for that as part of its search operation when looking for a > missing module; c.f. Python's automatic rebuilding of .pyc files from > .py files when former isn't found. (Q. How would this folder's > contents need to be represented to Python?) This is a bad idea. pyc files should be precompiled because it's often the case that the user of the .py files does not have access to create .pyc files in the same directory. Building .so files automatically is also an intractable problem, you obviously don't do much C programming ;) > -- Most packages should not require a setup.py script to install. > Users can, of course, employ their own generic shell script/executable > to [e.g.] unzip downloaded packages and mv them to their site-packages > folder. I find it easier that all modules and packages use a setup.py. No special cases. > -- Extensions distributed as source will presumably require some kind > of setup script in 'src' folder. Would this need to be a dedicated > Python script or would something like a standard makefile be > sufficient? Makefiles are no good. > -- Build operations should be handled by separate dedicated scripts > when necessary. Most packages should only require a generic shell > script/executable to zip up package folder and its entire contents > (minus .pyc and, optionally, .so files). What build operations are you talking about? Source distribution? python setup.py dist requires a very simple MANIFEST file that describes (by shell globbing) what files should be included/excluded. > - Remove metadata from setup.py and modules. All metadata should > appear in a single location: meta.txt file included in every package > folder. Use a single metadata scheme in simple structured nested > machine-readable plaintext format (modified Trove); example: MIME-ish is the Python standard and is what PyPI uses. Name: Foo Version: Bar .. > - Improve version control. Junk current "operators" scheme (=, <, >, > >=, <=) as both unnecessarily complex and inadequate (i.e. stating > module X requires module Y (>= 1.0) is useless in practice as it's > impossible to predict _future_ compatibility). Metadata should support > 'Backwards Compatibility' (optional) value indicating earliest version > of the module that current version is backwards-compatible with. > Dependencies list should declare name and version of each required > package (specifically, the version used as package was developed and > released). Version control system can then use both values to > determine compatibility. Example: if module X is at v1.0 and is > backwards-compatible to v0.5, then if module Y lists module X v0.8 as > a dependency then X 1.0 will be deemed acceptable, whereas if module Z > lists X 0.4.5 as a dependency then X 1.0 will be deemed unacceptable > and system should start looking for an older version of X. If you change the API to the point where it's not compatible anymore, you should change the name of the module. The new distutils dependencies stuff only does >=, I don't know where you got this "operators" idea. Maybe from packman? Packman has absolutely NOTHING to do with distutils. Packman verifies versions with arbitrary Python code because it's not feasible to have everyone adopt some standard versioning scheme immediately to support OS X users. > - Make it easier to have multiple installed versions of a module. > Ideally this would require including both name and version in each > module name so that multiple modules may coexist in same site-packages > folder. Note that this naming scheme would require alterations to > Python's module import mechanism and would not be directly compatible > with older Python versions (users could still use modules with older > Pythons, but would need to strip version from module name when > installing). This is much much much easier said than done. Easy solution: when the API changes, rename your package. That's never done in practice, though. > - Reject PEP 262 (installed packages database). Complex, fragile, > duplication of information, single point of failure reminiscent of > Windows Registry. Exploit the filesystem instead - any info a separate > db system would provide should already be available from each module's > metadata. At least one of these things needs to happen (a) all python packages and modules are refactored such that their metadata can be acquired without side-effects (b) a central database of this information should be established If (a) happens, then python's module visibility paths ends up being a really really slow and clunky central installed packages database. Which is usually good enough, unless you're using NFS or something, in which case installing a new package or auditing installed packages can take minutes or hours. This means that (b) should happen nomatter what, even if it is a cache of the information acquired from a full run of (a). -bob From bob at redivi.com Fri May 14 12:52:53 2004 From: bob at redivi.com (Bob Ippolito) Date: Fri May 14 12:52:56 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: <20040514162041.GD8360@dotnetslash.net> References: <20040514162041.GD8360@dotnetslash.net> Message-ID: <245B474E-A5C7-11D8-9B8C-000A95686CD8@redivi.com> On May 14, 2004, at 12:20 PM, Mark W. Alexander wrote: > On Fri, May 14, 2004 at 03:16:31PM +0100, has wrote: >> - Reject PEP 262 (installed packages database). Complex, fragile, >> duplication of information, single point of failure reminiscent of >> Windows Registry. Exploit the filesystem instead - any info a >> separate db system would provide should already be available from >> each module's metadata. > > I agree with rejecting 262 as well, but not in favor of the filesystem > but in favor of the native platform tools via bdist support. Solaris > people use pkgtools for everything. RH and friends use RPM. HP people > use SD-UX. Debianites use dpkg. etc. etc. etc.... God help those of us > supporting multiple platforms. > > In each case, absent [expletive deleted] commercial package installs, > all software and configuration management is consistent and, more > importantly, effective. Anything on top of that; CPAN, Distutils, > PEP 262, rogue admins with tarballs; _anything_ at all and people who > have to deal with anything over a handfull of machines WILL eventually > get caught with their pants down. > > If Distutils does not support simple, native package manager > integration, then it ceases to be a solution and becomes just one more > problem. A successfull implementation that creates native packages gets > immediate support from apt, yum, yast, urpmi, pkg-get, swinstall and > anything else, now and in the future. Not all operating systems have a usable package management system (Win32, Mac OS X, probably others). Not all users are superusers and can manipulate the system-wide database. Don't throw the baby out with the bathwater, PEP 262 can be revised such that it should cooperate with any existing platform specific database when possible and appropriate. -bob From hengist.podd at virgin.net Fri May 14 16:25:22 2004 From: hengist.podd at virgin.net (has) Date: Fri May 14 16:26:41 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: <40A4DB86.60704@sympatico.ca> References: <40A4DB86.60704@sympatico.ca> Message-ID: [Deep breath, everyone; it's gonna get longer before it gets shorter...;] Stefan Seefeld wrote: >Example: compilation of extension modules. > >Scons is aiming at providing an abstraction layer for portable compilation. >DU2 should at least allow to just delegate compilation of extension >modules to scons. >(and as I said previously, I think anything that doesn't allow to >wrap traditional build systems based on 'make' and possibly the autotools >is 'not good enough' in as a general solution). I'm far from expert on build systems (interpreted language weenie), but do think it makes sense for DU to hand off compilation duties to a third-party as quickly as it can. That third-party might be a separate Python-based system, or makefile, or anything else; however DU shouldn't need to know this. Thoughts on how one would separate extension compilation from the rest of the installation procedure... Let's say we had a standard 'src' folder to contain everything needed to produce a module's .so file(s), and we treat that folder basically as a self-contained entity. How would we instruct it to compile and deliver those .so files? The party requesting the compile operation should not need to know anything about the compilating system used. Presumably the easiest way to decouple the two is to have a standard 'compile.py' within the 'src' folder that is executed whenever somebody wants .so files created. Whatever code that compile.py file then executes is its own business, and if it needs any information from the OS/Python installation then it's up to it to request that information itself; ideally through existing Python APIs if possible, or through a specific DU API if not. Once that's done, it should be easy for developers to select their own build system from all those available to them. The Python-based build system that's currently incorporated into DU could, of course, be spun off as a peer to make, etc. - giving developers one more option to choose from without forcing it upon them. BTW, once .so compilation is decoupled from installation, it should be possible/practical/easy? to defer .so compilation to import time (as is currently done for .pyc files). >>- Every Python module should be distributed, managed and used as a >>single folder containing ALL resources relating to that module: >>sub-modules, extensions, documentation (bundled, generated, etc.), >>tests, examples, etc. (Note: this can be done without affecting >>backwards-compatibility, which is important.) Similar idea to OS >>X's package scheme, where all resources for [e.g.] an application >>are bundled in a single folder, but less formal (no need to hide >>package contents from user). > >are you really talking about 'package' here when you say 'module' ? >I don't think that mandating modules to be self contained is a good >idea. Often modules only 'make sense' in the context of the package >that contains them. Also, are you talking about how to distribute >packages, or about the layout of the installed files ? >I don't think DU2 should mandate any particular layout for the target >installation. It may well suggest layout of the files inside the >(not yet installed) package. (Like I say, rough notes; please keep pointing out where I'm not making sense.:) Basically, what I'm proposing is that module developers stop distributing 'naked' Python modules and use package format only (even when there's only a single .py file involved). We then take all the other stuff that's traditionally been bundled alongside the module/package - documentation, unit tests, examples, etc. - and put those into the package folder too. The term 'package' would basically become redundant; you could just describe everything as 'modules' and 'sub-modules'. It's largely a philosophical shift from treating .py and .so files as separate from source files, documentation, unit tests, examples, etc. to treating _all_ of them equally: each being an integral component of the module/package as a whole. It won't require any modifications to Python itself, since Python's import mechanism already supports the package format. For module developers, it's really just a logistical shift from being able to distribute 'bare' modules to always using package format. Module developers should be happy with this, given that it's much more accommodating towards documentation, unit tests, examples, etc. Stuff that they already need to put somewhere, and where better than as part of the module/package itself? And users should benefit too, as they'll always know where to look for documentation, etc. DU will benefit too in that the distributions will become much simpler to create: in most cases the only thing the developer will have to do is zip the package folder before uploading it, something that won't even require DU to do. (That's what I'm hoping for, anyway. In practice there might be some reason that I'm unaware of why certain platforms would require all that extra shuffle that DU currently does when installing packages - creating folders, copying files, etc. I'm not a cross-platform expert. But I'd be kinda surprised if that were the case.) [Sidenote: in an ideal world, a Python end-user should _never_ need to know whether FooLib exists in bare module or package form; the transition from operating in a file-based namespace to class-/object-based namespace would be seamless. Python's import statement is a bit flawed here; e.g. import foo.bar can be used when bar is a module/package within package foo, but not when it's a attribute in module foo.] >>- Question: is there any reason why modules should not be >>installable via simple drag-n-drop (GUI) or mv (CLI)? A standard >>policy of "the package IS the module" (see above) would allow a >>good chunk of both existing and proposed DU "features" to be gotten >>rid of completely without any loss of "functionality", greatly >>simplifying both build and install procedures. > >Again, I don't think it is DU2's role to impose anything concerning >the target layout. This is often platform dependent anyways. Not quite sure if we're talking on same wavelength here. Let me try to clarify my previous point first, then maybe you can explain yours to me (feel free to phrase it in terms even an idiot like me can understand; I won't be offended;). I'm talking of how a module/package gets put in a suitable Python directory (e.g. site-packages), which I'm assuming (unless proven otherwise) only requires that one knows which directory to put it in and moving the module/package to it. I'm also assuming that DU should not need to rearrange the contents of that package folder when installing it (except perhaps in special cases where it must install one of several platform-specific versions of a file, say; but that'll be the exception rather than the rule, and packages that don't require such special handling shouldn't need to go through the same in-depth procedures to install). I can't immediately see anything that DU adds to this process of duplicating a package folder from A to B, apart from filling my Terminal window with lots of technical-looking stuff about how it's creating new directories in site-packages and copying files over to them. Which looks impressive, but I'm not convinced is really necessary given a single 'mv' command can shift the package directory and all its contents over just fine from what I can tell. And if 95-100% of modules can be installed with just a simple mv, then let's make that the default procedure for installing modules and squeeze DU out of that part of the process too. >--Replace current system where user must explicitly state what they >want included with one where user need only state what they want >excluded. > >That depends on how much control users want over the process. I believe >both are equally valid, and should be supported (similar in spirit to >the MANIFEST.in syntax 'include' and 'exclude') The problem I see is that manifests seem to be involved whether you need/want them or not. If [as I'm assuming] the majority of distributions are trivial to assemble, then manifests should be the exception, not the rule. I dunno how other folks work, but in my Home folder I have a PythonDev folder containing folders for each of my module projects - FooDev, BarDev, etc. Within each of these I have a folder named Distro, which contains all the files and folders that'll go into my distribution. For me, manifests are nothing but a menace: this folder setup already makes clear what I want put into the distribution, and I can't see why I should have to explain it twice to the stupid machine. There's been several occasions where an error or omission in a manifest file has gone unnoticed until I've received an email from a user to say that the package they downloaded is missing some parts (embarrassing). Right now I manually unzip and check distributions before uploading, but this is kinda crazy; I shouldn't have to worry that DU might have screwed up a build, seeing as one of the reasons for automating the process should be to avoid making such mistakes. Thus my conclusion: explicit inclusion is inherently unsafe; a single mistake or forgetting to update the manifest file to keep it in sync with changes to the package can easily result in a broken distribution. A much more sensible default is to include everything by default, and leave it to the developer to exclude anything they don't want included. The worst accident likely to occur here with any regularity is that you forget to strip out a few .pyc files resulting in a distribution that's a few KB bigger than it really needs to be. Plus it adheres to the philosophy that the most common case should require the least amount of work: in this case, the majority of modules won't ever require a manifest file and can safely skip it. [BTW, will check out the include/exclude feature which I wasn't previously aware of. Though my argument would be that I shouldn't need to know about such 'advanced' features just to produce a simple, reliable distribution: the process should be as simple as falling off a log to begin with.] ... We can take this manifest issue quite a bit further, btw. Another big frustration with the things is they're quite brain-dead. All I want to say is "Package everything in Folder X for distribution except for .pyc and .so files". Thus a more pragmatic approach might be to do away with dumb manifest files completely, and leave the developer to optionally supply a 'build.py' script that will be automatically executed as part of the build process. >>-- In particular, removing most DU involvment from build procedures >>would allow developers to use their own development/build systems >>much more easily. > >yes !! Though that's more easily said than done: a minimum of collaboration >between the two is required, at least the adherence to some conventions. Of course (see earlier comments). Just how many... no, _few_ conventions would be needed? >>- Installation and compilation should be separate procedures. > >As a starting point, the whole 'build_ext' mechanism should be re-evaluated. >The current 'Extension' mechanism is by far not abstract enough. Either >the build_ext or the Extension class should be made polymorphic to wrap >any external build system that could be used (make, scons, jam, ...) Or invert and decouple the process to put the [e.g.] 'src/compile.py' script in control.In this case, I think we could greatly simplify the extension building process if DU can say to the 'src' folder: "Build me some .so files", then stand back and let it get on with it (while being happy to lend any support if/when it's asked for). [i.e. It's a mental trick I often try when trying to resolve an API design: seeing if I can switch from a complex 'push' process to a simpler 'pull' process (or from a complex 'pull' process to a simpler 'push' process). It can make quite a difference.] >>- What else may setup.py scripts do apart from install modules (2) >>and build extensions (3)? > >* building documentation (that, too, is highly domain specific. From > Latex over Docbook to doxygen...) Yup. So let's say we have a standard 'docs' folder within a package that may optionally contain a 'format.py' script that will be called as necessary. >* running unit tests Have a standard 'tests' folder containing an optional 'test.py' script. (Hey, think I see a pattern evolving here...) >>- Remove metadata from setup.py and modules. > >I don't quite agree in general. What metadata are we talking about >anyways ? There's metadata that is to be provided to the packager >backends, i.e. a package description of some sort. Some of these >can be generated automatically (such as MANIFEST.in -> MANIFEST, >build / host platform, etc.), others have to be explicitely provided >(maintainer address, package description). I mean user-defined metadata (I'll assume those that generate metadata automatically for their own consumption can be left to handle that as best suits themselves): 1. A module may contain various bits of user-defined metadata, e.g. __version__, __author__. This info is almost certainly recorded elsewhere, so [afaik] shouldn't need to be duplicated here. 2. The setup.py script also contains module name, version, author, etc... potentially quite a lot of metadata, in fact. All mooshed together with code for building and installing packages. We should move this data out of there into a separate, dedicated metadata file that's included in each package. >Having 'all metadata' lumped together brings us back to the 'swiss >army knife' syndrome. Well, swiss armyness is always a concern. If it's really a problem here, we'd just need to have more than one metadata file. But I don't think it'll come to that. Also, one great advantage of pulling metadata out of module and setup.py files is that it'll make it much easier for other clients to access it. Right now it's kinda locked away: the only folks who know how to access and use it are Python (module metadata) and DU (setup.py metadata). >- Improve version control. Junk current "operators" scheme (=, ><, >, >=, <=) as both unnecessarily complex and inadequate (i.e. >stating module X requires module Y (>= 1.0) is useless in practice >as it's impossible to predict _future_ compatibility). Metadata >should support 'Backwards Compatibility' (optional) value indicating >earliest version of the module that current version is >backwards-compatible with. Dependencies list should declare name and >version of each required package (specifically, the version used as >package was developed and released). > >Good idea, though this issue highly depends on the packager backend used. Could you cite some examples to help me understand the issues involved? >- Make it easier to have multiple installed versions of a module. > >That, too, isn't really an DU2 issue, or is it ? Not really; more a general packaging and Python import issue. But I included it here as I think packaging issues have a big impact on DU policy. >>- Reject PEP 262 (installed packages database). Complex, fragile, >>duplication of information, single point of failure reminiscent of >>Windows Registry. Exploit the filesystem instead - any info a >>separate db system would provide should already be available from >>each module's metadata. > >I don't quite agree. I couldn't live without rpm these days. Well, it's not to say that users can't build their own databases listing all their installed gunk if they want to. Ensuring user freedom in such areas is crucial. Perhaps it would be clearer to say that the intention is sound (make information on installed modules easy to retrieve; something I'm all for), but the way 262 proposes to do it is not. In fact, one of my main objections to 262 is that it could well restrict user freedom: by creating lots of dependencies and synchronisation issues, users could find themselves locked into using a single 'official' Package Manager because it's the only one smart enough to deal with all these complexities. Users who venture into their site-packages folder by any other means will quickly find themselves being punished the PackMan Police for unlawful infractions. This should be one of the benefits that comes from decoupling module metadata from implementation as I've suggested above. There'll be no need for a central authority (262's DB) to maintain metadata, because each module already contains and looks after its own. And because there's only one metadata instance in existence for each module, there's no dependency/synchronisation issues to worry about. You can still provide users with exactly the same API that the 262 DB would have done for accessing this info, of course, so you still get all the functionality 262 would have provided, but without any of the headaches. Funnily enough though, one of the possible DB implementations floated for 262 is to put the metadata for each module into a separate file on disk. So perhaps I should say that 262's idea of maintaining a _separate_ database simply isn't necessary: all the info it would have provided can already be retrieved from files in the filesystem; the only difference is that each file is bundled in package. The module/file system _is_ the database, if you like. (After all, what's a filesystem but a big ol' object database by any other name?;) Thanks, has p.s. If you're interested, you can see a module system I designed a couple years back at applemods.sourceforge.net. It actually uses a version of the "module = package = distribution with all batteries included" concept I'm floating here. (Which I think was itself influenced by Python's package system.) p.p.s. Anything folk can do to help me understand the issues involved in cross-platform and extension compilation lest I spout off too much about things I know not will be much appreciated, ta. :) -- http://freespace.virgin.net/hamish.sanderson/ From bcmrshcprbfr at msn.com Fri May 14 08:15:23 2004 From: bcmrshcprbfr at msn.com (Jose Travis) Date: Fri May 14 18:09:59 2004 Subject: [Distutils] Re: did I send this to you? Message-ID: <200405141117.i4EBHGWP005110@mxzilla1.xs4all.nl> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040514/add1c1d3/attachment.html From lars at ibp.de Fri May 14 18:23:32 2004 From: lars at ibp.de (Lars Immisch) Date: Fri May 14 18:23:28 2004 Subject: Strong and weak points of distutils 1 Was: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: <245B474E-A5C7-11D8-9B8C-000A95686CD8@redivi.com> References: <20040514162041.GD8360@dotnetslash.net> <245B474E-A5C7-11D8-9B8C-000A95686CD8@redivi.com> Message-ID: <40A546E4.9090608@ibp.de> Dear all, I have not used distutils very much, but maybe in some slightly unusual situations. I'll briefly summarize what I believe are the strong and the weak points. Strong points: - support for binary installers. (I was compelled to use distutils in the first place because it is so easy to create Windows installers - which is a massive pain otherwise) - basic C extensions multi platform compilation support is quite good. Sometimes library names must be adjusted across Windows/Unix, but that is often enough and much less painful than writing multiple makefiles (GNU make and nmake at least, not to mention the inter-Unix differences) Weak points: - build processes with more stages than compile and link need to extend distutils. - insufficient SWIG support. Both these weak points come from my experience with wrapping third party libraries into Python with SWIG. I typically generate the SWIG input files from the third-party headers and feed it into SWIG to get the C source, so I have preprocess, swig, compile and link as stages. So: - I'd like the C extension build system to be more loosely coupled from distutils or opened up, if only by more documentation (I don't know SCons first hand) - I'd like to continue to get information from distutils how Python was compiled, linked and installed. - Lars From Bob: > Not all operating systems have a usable package management system > (Win32, Mac OS X, probably others). What's wrong with Installer.app and/or PackageMaker? On Windows, there is MSI (but I will admit I have given up in disgust trying to create even a trivial installer "manually" with Orca.exe). From ronaldoussoren at mac.com Sat May 15 02:00:17 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat May 15 02:00:09 2004 Subject: Strong and weak points of distutils 1 Was: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: <40A546E4.9090608@ibp.de> References: <20040514162041.GD8360@dotnetslash.net> <245B474E-A5C7-11D8-9B8C-000A95686CD8@redivi.com> <40A546E4.9090608@ibp.de> Message-ID: <23D122C2-A635-11D8-9E35-0003931CFE24@mac.com> On 15-mei-04, at 0:23, Lars Immisch wrote: > From Bob: > >> Not all operating systems have a usable package management system >> (Win32, Mac OS X, probably others). > > What's wrong with Installer.app and/or PackageMaker? Both are installers, not package management systems. There is no public interface for listing which packages are installed and uninstalling packages, let alone dependency management. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From ronaldoussoren at mac.com Sat May 15 02:28:40 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat May 15 02:28:30 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: References: <40A4DB86.60704@sympatico.ca> Message-ID: <1B29DDE6-A639-11D8-9E35-0003931CFE24@mac.com> On 14-mei-04, at 22:25, has wrote: > [Deep breath, everyone; it's gonna get longer before it gets > shorter...;] > > Stefan Seefeld wrote: > >> Example: compilation of extension modules. >> >> Scons is aiming at providing an abstraction layer for portable >> compilation. >> DU2 should at least allow to just delegate compilation of extension >> modules to scons. >> (and as I said previously, I think anything that doesn't allow to >> wrap traditional build systems based on 'make' and possibly the >> autotools >> is 'not good enough' in as a general solution). > > I'm far from expert on build systems (interpreted language weenie), > but do think it makes sense for DU to hand off compilation duties to a > third-party as quickly as it can. That third-party might be a separate > Python-based system, or makefile, or anything else; however DU > shouldn't need to know this. DU should know about it, it should be easier to itegratie DU with other build systems but DU should still know about building extensions. For this reason I also don't like your idea of splitting of various tasks into seperate python scripts, that doesn't really solve anything, e.g. why is writing a script named test.py *inherently* easier than writing a test action for distutils. What's needed is an easier way to write and adapt DU actions, and to get tool-builders to include DU-actions/subactions with their tools. Pyrex already includes an build_ext action that will convert .pyx file to C, SWIG could do the same, as could docutils, unittest frameworks, ... BTW. what I like about distutils is that it provides an easy to recognize standard interface for installing python libraries. When I download a new python library and it includes a setup.py script I'm a happy camper, because I can install using 'python setup.py install' (*). When there's no setup.py script I've to read installation instructions, and often have to do various manual steps before I can install. (*) In theory of course, in practice C extensions often need help to tell them where libraries are and which features are available in those libraries. I guess DU needs autoconf-like functionality for detecting features of (C-) libraries. > > >>> - Question: is there any reason why modules should not be >>> installable via simple drag-n-drop (GUI) or mv (CLI)? A standard >>> policy of "the package IS the module" (see above) would allow a good >>> chunk of both existing and proposed DU "features" to be gotten rid >>> of completely without any loss of "functionality", greatly >>> simplifying both build and install procedures. >> >> Again, I don't think it is DU2's role to impose anything concerning >> the target layout. This is often platform dependent anyways. I do like the idea of having a standard location for documetation and examples though. A prefered source layout would also help (e.g. if you don't specify anything at all distutils could assume everything inside 'Lib' is a python module, everything in 'Doc' is documentation and the unittests are in 'Testsuite'). > > Not quite sure if we're talking on same wavelength here. Let me try to > clarify my previous point first, then maybe you can explain yours to > me (feel free to phrase it in terms even an idiot like me can > understand; I won't be offended;). Linux systems often have standard locations for placing documenation (such as /usr/share/doc/), and likewise for other unix systems. If Python would place it's documentation elsewhere users would get confused. > > I'm talking of how a module/package gets put in a suitable Python > directory (e.g. site-packages), which I'm assuming (unless proven > otherwise) only requires that one knows which directory to put it in > and moving the module/package to it. I'm also assuming that DU should > not need to rearrange the contents of that package folder when > installing it (except perhaps in special cases where it must install > one of several platform-specific versions of a file, say; but that'll > be the exception rather than the rule, and packages that don't require > such special handling shouldn't need to go through the same in-depth > procedures to install). You seem to be muddying the definition of a package. There's a python package as a specific language construct and there's python package as "a distribution of a python library", which are seperate entities. Merging them is IMHO confusing. With little effort every python library could be placed into it's own subdirectory in site-packages: .../site-packages/ MyPackage.pth MyPackage/ module1.py package1/ __init__.py module2.py If the 'extra_path' argument of setup() were to be required we'd have a directory to that can be used to store additional information, and it would make d&d package management easier for those who like that. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From ronaldoussoren at mac.com Sat May 15 09:12:55 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat May 15 09:12:41 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: References: <40A4DB86.60704@sympatico.ca> Message-ID: <945EBF44-A671-11D8-9E35-0003931CFE24@mac.com> On 14-mei-04, at 22:25, has wrote: > [Deep breath, everyone; it's gonna get longer before it gets > shorter...;] > > Stefan Seefeld wrote: > >> Example: compilation of extension modules. >> >> Scons is aiming at providing an abstraction layer for portable >> compilation. >> DU2 should at least allow to just delegate compilation of extension >> modules to scons. >> (and as I said previously, I think anything that doesn't allow to >> wrap traditional build systems based on 'make' and possibly the >> autotools >> is 'not good enough' in as a general solution). > > I'm far from expert on build systems (interpreted language weenie), > but do think it makes sense for DU to hand off compilation duties to a > third-party as quickly as it can. That third-party might be a separate > Python-based system, or makefile, or anything else; however DU > shouldn't need to know this. DU should know about it, it should be easier to itegratie DU with other build systems but DU should still know about building extensions. For this reason I also don't like your idea of splitting of various tasks into seperate python scripts, that doesn't really solve anything, e.g. why is writing a script named test.py *inherently* easier than writing a test action for distutils. What's needed is an easier way to write and adapt DU actions, and to get tool-builders to include DU-actions/subactions with their tools. Pyrex already includes an build_ext action that will convert .pyx file to C, SWIG could do the same, as could docutils, unittest frameworks, ... BTW. what I like about distutils is that it provides an easy to recognize standard interface for installing python libraries. When I download a new python library and it includes a setup.py script I'm a happy camper, because I can install using 'python setup.py install' (*). When there's no setup.py script I've to read installation instructions, and often have to do various manual steps before I can install. (*) In theory of course, in practice C extensions often need help to tell them where libraries are and which features are available in those libraries. I guess DU needs autoconf-like functionality for detecting features of (C-) libraries. > > >>> - Question: is there any reason why modules should not be >>> installable via simple drag-n-drop (GUI) or mv (CLI)? A standard >>> policy of "the package IS the module" (see above) would allow a good >>> chunk of both existing and proposed DU "features" to be gotten rid >>> of completely without any loss of "functionality", greatly >>> simplifying both build and install procedures. >> >> Again, I don't think it is DU2's role to impose anything concerning >> the target layout. This is often platform dependent anyways. I do like the idea of having a standard location for documetation and examples though. A prefered source layout would also help (e.g. if you don't specify anything at all distutils could assume everything inside 'Lib' is a python module, everything in 'Doc' is documentation and the unittests are in 'Testsuite'). > > Not quite sure if we're talking on same wavelength here. Let me try to > clarify my previous point first, then maybe you can explain yours to > me (feel free to phrase it in terms even an idiot like me can > understand; I won't be offended;). Linux systems often have standard locations for placing documenation (such as /usr/share/doc/), and likewise for other unix systems. If Python would place it's documentation elsewhere users would get confused. > > I'm talking of how a module/package gets put in a suitable Python > directory (e.g. site-packages), which I'm assuming (unless proven > otherwise) only requires that one knows which directory to put it in > and moving the module/package to it. I'm also assuming that DU should > not need to rearrange the contents of that package folder when > installing it (except perhaps in special cases where it must install > one of several platform-specific versions of a file, say; but that'll > be the exception rather than the rule, and packages that don't require > such special handling shouldn't need to go through the same in-depth > procedures to install). You seem to be muddying the definition of a package. There's a python package as a specific language construct and there's python package as "a distribution of a python library", which are seperate entities. Merging them is IMHO confusing. With little effort every python library could be placed into it's own subdirectory in site-packages: .../site-packages/ MyPackage.pth MyPackage/ module1.py package1/ __init__.py module2.py If the 'extra_path' argument of setup() were to be required we'd have a directory to that can be used to store additional information, and it would make d&d package management easier for those who like that. Ronald -- X|support bv http://www.xsupport.nl/ T: +31 610271479 F: +31 204416173 From BVXHGPX at mail.goo.ne.jp Sat May 15 10:57:58 2004 From: BVXHGPX at mail.goo.ne.jp (Rolland Steele) Date: Sat May 15 19:55:28 2004 Subject: [Distutils] no need to lie on your application, we can sell you a verifiable university degree Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040515/a1eb1668/attachment.html From Paul.Moore at atosorigin.com Mon May 17 06:18:46 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Mon May 17 06:18:49 2004 Subject: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2 Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060EAC@UKDCX001.uk.int.atosorigin.com> From: Ronald Oussoren > On 15-mei-04, at 0:23, Lars Immisch wrote: >> From Bob: >> >>> Not all operating systems have a usable package management system >>> (Win32, Mac OS X, probably others). >> >> What's wrong with Installer.app and/or PackageMaker? > Both are installers, not package management systems. There is no public > interface for listing which packages are installed and uninstalling > packages, let alone dependency management. Hmm. I'm not sure I see what you're saying here. If you're saying that a "usable package management system" needs to support a "public interface" for listing which packages are installed, uninstalling packages, and dependency management (which you'd need to define more clearly) then Windows certainly does have one (albeit a bit primitive). Applications which wish to participate in the standard "Add/Remove Programs" interface have to register certain registry keys, so to some extent that would count as a "public interface". Listing & uninstall only, there's no dependency management, but it's a start. And it's what the current bdist_wininst uses, so it's supported by distutils right now. What, specifically, do you need the OS to provide, and why? What real problem exists with the current system? (At least in the context of the "build a standard OS package" commands, like bdist_wininst, bdist_rpm, etc). The only major issue I see is dependency management, and, personally, I'm happy to treat this as a documentation issue (package X documents that it relies on package Y, version a.b or later, and package Z, version c.d). Of course, I don't want automatic downloading of dependencies, uninstalling of dependencies when a package is uninstalled, etc, which maybe others do... 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. __________________________________________________________________________ From ronaldoussoren at mac.com Mon May 17 06:30:17 2004 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon May 17 06:30:18 2004 Subject: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2 In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060EAC@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8803060EAC@UKDCX001.uk.int.atosorigin.com> Message-ID: <3095CC66-A7ED-11D8-9E35-0003931CFE24@mac.com> On 17-mei-04, at 12:18, Moore, Paul wrote: > From: Ronald Oussoren >> On 15-mei-04, at 0:23, Lars Immisch wrote: >>> From Bob: >>> >>>> Not all operating systems have a usable package management system >>>> (Win32, Mac OS X, probably others). >>> >>> What's wrong with Installer.app and/or PackageMaker? > >> Both are installers, not package management systems. There is no >> public >> interface for listing which packages are installed and uninstalling >> packages, let alone dependency management. > > Hmm. I'm not sure I see what you're saying here. If you're saying that > a > "usable package management system" needs to support a "public > interface" > for listing which packages are installed, uninstalling packages, and > dependency management (which you'd need to define more clearly) then > Windows certainly does have one (albeit a bit primitive). Installer.app is for MacOS X. The big problem with Installer.app is that it can *only* be used to install application, Apple doesn't include an application to uninstall software. > > Applications which wish to participate in the standard "Add/Remove > Programs" > interface have to register certain registry keys, so to some extent > that > would count as a "public interface". Listing & uninstall only, there's > no > dependency management, but it's a start. And it's what the current > bdist_wininst uses, so it's supported by distutils right now. > > What, specifically, do you need the OS to provide, and why? What real > problem exists with the current system? (At least in the context of > the "build a standard OS package" commands, like bdist_wininst, > bdist_rpm, > etc). The only major issue I see is dependency management, and, > personally, > I'm happy to treat this as a documentation issue (package X documents > that > it relies on package Y, version a.b or later, and package Z, version > c.d). > Of course, I don't want automatic downloading of dependencies, > uninstalling > of dependencies when a package is uninstalled, etc, which maybe others > do... I'll let others answer this question, I've never used the bdist_* commands (other than bdist_dumb). Ronald From distutils-sig at claytonbrown.net Mon May 17 09:09:51 2004 From: distutils-sig at claytonbrown.net (distutils-sig@claytonbrown.net) Date: Mon May 17 09:08:41 2004 Subject: [Distutils] Module Versioning. In-Reply-To: Message-ID: <000001c43c10$3d87a6a0$0a07a8c0@ab1tch> I noticed a Module Versioning import technique in a module PythonMegaWidgets(http://pmw.sourceforge.net/) Is there any reason as to why this technique could not be applied to the site-packages directory to allow more control of which version of a module is used. Does anyone know if anyone else come up with a more appropriate solution to this problem. Perhaps this could be improved with a versionmodule.py , which could sniff a module sugesting/allowing user input of a module major_minor_patch, moving it into a versioned directory. Allowing setup.py's to behave as they do. Are there any other standard practices which allow specification of a modules version at time of import / site-packages with module versions, that is known not to introduce problems when using disutils/p2exe etc. Clay. From ZGNFCLGGMDRM at hstrmain.str.hitachi.co.jp Sun May 16 17:47:45 2004 From: ZGNFCLGGMDRM at hstrmain.str.hitachi.co.jp (Williams Yoder) Date: Mon May 17 11:09:19 2004 Subject: [Distutils] didn't go to college - that's ok we'll give you a diploma Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040516/dc1d733f/attachment.html From slash at dotnetslash.net Mon May 17 17:08:22 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Mon May 17 17:08:27 2004 Subject: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2 In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060EAC@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8803060EAC@UKDCX001.uk.int.atosorigin.com> Message-ID: <20040517210822.GA17099@dotnetslash.net> On Mon, May 17, 2004 at 11:18:46AM +0100, Moore, Paul wrote: > What, specifically, do you need the OS to provide, and why? What real > problem exists with the current system? (At least in the context of > the "build a standard OS package" commands, like bdist_wininst, bdist_rpm, > etc). The only major issue I see is dependency management, and, personally, > I'm happy to treat this as a documentation issue (package X documents that > it relies on package Y, version a.b or later, and package Z, version c.d). > Of course, I don't want automatic downloading of dependencies, uninstalling > of dependencies when a package is uninstalled, etc, which maybe others do... In my view of the perfect world, the OS tools would deal with dependencies based on the metadata provided by the binary packages. This is how apt-get works. It wraps around dpkg and/or rpm. The .deb and .rpm packages provide the metadata and apt goes and gets whatever is necessary. It does not prevent people from pulling down individual .deb or .rpm files and working their way through (or even overriding) dependencies, if that's what they want to do. Nor is it required that you have an automatic dependency resolver ala apt. Since Windows does not provide that ability natively, then Distutils need not try to extend Windows to include it. Although an independent "apt-for-Windows" type too would, I'm sure, be appreciated by Windows users, it is not necessary for Windows package management any more than apt is required for .deb or .rpm management. RPM managed quite well for some time before apt-like tools became available -- It's only advantage over Windows "Add/Remove Programs" was dependency checking (not dependency resolution). 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. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From easmith at purinmail.com Mon May 17 18:59:15 2004 From: easmith at purinmail.com (Cheerios P. Epitomizing) Date: Tue May 18 00:02:46 2004 Subject: [Distutils] Have a nice day! //the righteousness of Jesus Christ, therefore man is justified Message-ID: <101101c43b99$a737d618$023a2cad@purinmail.com> Get easy money! http://members.lycos.co.uk/lancer131/1/ --- when the temptation comes again with power, he is carried From vdtak at mpifr-bonn.mpg.de Tue May 18 04:12:01 2004 From: vdtak at mpifr-bonn.mpg.de (Floris van der Tak) Date: Tue May 18 04:12:15 2004 Subject: [Distutils] distutils install probs on suse 9.0 Message-ID: Dear Distutils, my attempt to install the distutils on suse 9.0 (which provides python 2.3) fails: python/Distutils-1.0.2> python setup.py build Traceback (most recent call last): File "setup.py", line 30, in ? packages = ['distutils', 'distutils.command'], File "/home/floris/lib/python/Distutils-1.0.2/distutils/core.py", line 101, in setup _setup_distribution = dist = klass(attrs) File "/home/floris/lib/python/Distutils-1.0.2/distutils/dist.py", line 130, in __init__ setattr(self, method_name, getattr(self.metadata, method_name)) AttributeError: DistributionMetadata instance has no attribute 'get___doc__' Your help would be appreciated, Floris van der Tak From Paul.Moore at atosorigin.com Tue May 18 04:46:49 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Tue May 18 04:46:54 2004 Subject: Strong and weak points of distutils 1 Was: [Distutils] thoughtson distutils 1 & 2 Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060EAE@UKDCX001.uk.int.atosorigin.com> 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. __________________________________________________________________________ From mwh at python.net Tue May 18 07:30:17 2004 From: mwh at python.net (Michael Hudson) Date: Tue May 18 07:30:24 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: (Floris van der Tak's message of "Tue, 18 May 2004 10:12:01 +0200 (MET DST)") References: Message-ID: <2mhdueht12.fsf@starship.python.net> Floris van der Tak writes: > Dear Distutils, > > my attempt to install the distutils on suse 9.0 (which provides python > 2.3) fails: Python 2.3 should include distutils. If it's not installed, it must be part of some other RPM that Suse provides. Cheers, mwh -- And then the character-only displays went away (leading to increasingly silly graphical effects and finally to ads on web pages). -- John W. Baxter, comp.lang.python From david at handysoftware.com Tue May 18 07:43:53 2004 From: david at handysoftware.com (David Handy) Date: Tue May 18 07:42:02 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: Message-ID: On Tue, 18 May 2004, Floris van der Tak wrote: > my attempt to install the distutils on suse 9.0 (which provides python > 2.3) fails: Why are you installing distutils on a system that already has Python 2.3 installed? Python 2.3 normally comes with distutils as part of the Python standard library. Did suse distribute a version of Python that had distutils removed? > > python/Distutils-1.0.2> python setup.py build > Traceback (most recent call last): > File "setup.py", line 30, in ? > packages = ['distutils', 'distutils.command'], > File "/home/floris/lib/python/Distutils-1.0.2/distutils/core.py", line > 101, in setup > _setup_distribution = dist = klass(attrs) > File "/home/floris/lib/python/Distutils-1.0.2/distutils/dist.py", line > 130, in __init__ > setattr(self, method_name, getattr(self.metadata, method_name)) > AttributeError: DistributionMetadata instance has no attribute > 'get___doc__' > It appears from this stack trace that the error is occurring in a version of distutils located in /home/floris/lib/python/Distutils-1.0.2/ . Did you previously install distutils to that directory, or is that the directory you are running setup.py from? > > Your help would be appreciated, > > Floris van der Tak Good luck. From mats at laplaza.org Tue May 18 09:14:42 2004 From: mats at laplaza.org (Mats Wichmann) Date: Tue May 18 09:15:06 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: References: Message-ID: <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> At 05:43 AM 5/18/2004, David Handy wrote: >On Tue, 18 May 2004, Floris van der Tak wrote: > >> my attempt to install the distutils on suse 9.0 (which provides python >> 2.3) fails: > >Why are you installing distutils on a system that already has Python 2.3 >installed? Python 2.3 normally comes with distutils as part of the Python >standard library. > >Did suse distribute a version of Python that had distutils removed? It should come from python-devel From DRDPL at cashette.com Tue May 18 02:21:29 2004 From: DRDPL at cashette.com (Sonya Pina) Date: Tue May 18 16:32:51 2004 Subject: [Distutils] Receive big discounts on MS Win 2000, XP, Office, Adobe, Corel products from Todd's Stuff Store Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040518/174c3fc7/attachment.html From hengist.podd at virgin.net Tue May 18 18:29:27 2004 From: hengist.podd at virgin.net (has) Date: Tue May 18 18:33:17 2004 Subject: [Distutils] thoughts on distutils 1 & 2 Message-ID: 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 (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/ From vdtak at mpifr-bonn.mpg.de Wed May 19 04:22:59 2004 From: vdtak at mpifr-bonn.mpg.de (Floris van der Tak) Date: Wed May 19 04:24:13 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> Message-ID: Distutils was indeed part of python-devel, which is on the dvd, but is not part of the standard installation. Thanks for your help, Floris On Tue, 18 May 2004, Mats Wichmann wrote: > At 05:43 AM 5/18/2004, David Handy wrote: > >On Tue, 18 May 2004, Floris van der Tak wrote: > > > >> my attempt to install the distutils on suse 9.0 (which provides python > >> 2.3) fails: > > > >Why are you installing distutils on a system that already has Python 2.3 > >installed? Python 2.3 normally comes with distutils as part of the Python > >standard library. > > > >Did suse distribute a version of Python that had distutils removed? > > It should come from python-devel > > From postmaster at wi.mit.edu Wed May 19 05:20:11 2004 From: postmaster at wi.mit.edu (postmaster@wi.mit.edu) Date: Wed May 19 05:20:14 2004 Subject: [Distutils] Content violation Message-ID: Content violation found in email message. From: distutils-sig@python.org To: 40183c47.2050308@wi.mit.edu File(s): schock.com Matching filename: *.com From slash at dotnetslash.net Wed May 19 10:26:22 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Wed May 19 10:29:32 2004 Subject: [Distutils] thoughts on distutils 1 & 2 In-Reply-To: References: Message-ID: <20040519142622.GA22177@dotnetslash.net> On Tue, May 18, 2004 at 11:29:27PM +0100, has wrote: > > - 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. Distutils "wraps" native package managers in the sense that it can use native package management tools to produce native binary packages for a specific target. This is, however, only one possible method. Others would include libraries (i.e. rpmlib) or some other method of producing a file that the package manager understands. For example a "binary package" is usually a standard archive file (such as cpio or ar archive) that contains specific files that the package manager uses for control (i.e., CONTROL for .debs). The reasoning is consistent software configuration management. DU does not require that you produce binary packages. You can just "python setup.py install" where ever you want. Or you could "python setup.py bdist_dumb" to produce a binary compatible tarball. By producing platform native binary packages, Distutils automatically "scales" as far as the platform scales. As far as "lock-in" goes, the platforms include their package management so you're no more locked in the that tool than you are to the platform. Distutils reduces that lock-in by supporting the instant re-packaging into binary packages for a different platform's manager. > > - 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]) This, too, is addressed be effective metadata management. Specifiying which files are package/module files, which are doc files, which are data files and which are config files supports bdist_* implementations that do the right thing for the installation target. None of this eliminates the "generic installer" concept. Both "python setup.py install" and bdist_dump can be considered "generic installers". I think the only thing that would be required is, perhaps, a distutils utility function available to modules that would find a module configuration file so it can adjust itself at runtime. For example: from distutils import configure configure() could setup appropriate path variables for config, data and doc files. Package/module files need to go to the "right" place (site-packages or somewhere that the user can put in PYTHONPATH). Distutils can't futz with package/module locations without breaking the import mechanism. (I think this is more relevant to applications that contain application specific packages than general library packages.) > - 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.) This is, I think, the distinction between "applications" and library packages. Eroaster comes to mind as an "application". On Debian, eroaster has /usr/lib/eroaster for modules and /usr/share/eroaster for icons. It's not likely that a python developer is going to do an import of an eroaster module because the components are too application specific to be of general use. It doesn't make sense to me to plop the eroaster modules in site-packages. Applications are a tightly integrated set of modules that must all be in place for the application to function. General purpose library packages would be your "single-task" components. These need to be treated differently. > - 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. Separating into individual scripts isn't any easier or more intuitive than providing subclass-able objects. Distutils commands and processes are subclass-able and customizable now, although (last time I looked) it's not documented well enough for a non-Distutils hacker to leverage. > - 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.) Personally, I find nothing more annoying than a source package that includes ./configure that is not the autoconf-style ./configure that it appears to be at a glance. I think it's important that setup.py remain not only as an indicator that the package is Distutils "enabled" but that it is Distutils "consistent." > - 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. I've done several packages and never once manually created a manifest. Doing a setup.py for someone else's package, it did "intellegently exclude required .xml files. I agree that absent a manifest file, everything in the source tree should be transfered to the build/install trees. > - 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). What would be the purpose of nesting? If it's supporting related-but-independent sub-packages, I'm for it. I agree that the metadata format is irrelevant as long as it meets the criteria you note. > - 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! Sounds like including setup.cfg in the installation tree would accomplish what you describe. > 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. Unfortunately, I don't have authorization to release any of mine, however, in the current architecture _every_ distutils based distribution _is_ binary capable. Everything I've needed, I've been able to produce a binary distribution for Solaris* with: python setup.py bdist_pkgtool \ [--pkg-abrev="pkgtool's stupid 8 char max name"] For HP-UX: python setup.py bdist_sdux For rpm: python setup.py bdist_rpm For Debian (cheating ;): python setup.py bdist_rpm alien --to-deb [resulting.rpm] Whether the package author _intended_ for the packages to be binary installable or not has made _no_difference_at_all_. THIS IS THE POWER OF DISTUTILS: The package author doesn't need to know or care what the target platform will be, what the binary package format is, or how to produce them. They don't even have to know what native package managers exist. If there's a setup.py, Distutils "just works" to produce a native binary package. So for an example of a "DU-based binary distribution", see _any_ DU-based package. mwa *_still_ waiting management approval to release bdist_pkgtool and bdist_sdux..... -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From hengist.podd at virgin.net Wed May 19 12:14:57 2004 From: hengist.podd at virgin.net (has) Date: Wed May 19 12:23:36 2004 Subject: [Distutils] thoughts on distutils 1 & 2 (addendum) Message-ID: 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/ From pje at telecommunity.com Wed May 19 13:22:45 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed May 19 13:22:36 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: References: <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> Message-ID: <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> At 10:22 AM 5/19/04 +0200, Floris van der Tak wrote: >Distutils was indeed part of python-devel, which is on the dvd, >but is not part of the standard installation. > >Thanks for your help, Floris Somebody should probably provide feedback to the packager that they shouldn't yank out arbitrary parts of the Python distribution into separate (OS-level) packages. The standard library is the standard library: it should not be subdivided. From slash at dotnetslash.net Wed May 19 13:33:21 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Wed May 19 13:33:25 2004 Subject: [Distutils] thoughts on distutils 1 & 2 (addendum) In-Reply-To: References: Message-ID: <20040519173321.GB22688@dotnetslash.net> On Wed, May 19, 2004 at 05:14:57PM +0100, has wrote: > 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. You keep saying "the .zip" as if that's the only, or possibly prefered, distribution mechanism. It sounds as if your exposure to heterogenous systems is pretty limited and I think you are imposing the limitations of your view onto Distutils. Your recurring recommendations for monolithic scripts, such as build.py, install.py, whatever.py also seems to be a step backward from Distutils current capabilities. The functionality I think you intend by these scripts is already integrated in Distutils. It is accomplished by subclassing the build and install command classes or their helper commands. In an object oriented language, this is the appropriate way to re-use code; Not to have to include duplicate scripts in each package's source tree. Please review some more setup.py scripts. I agree that metadata should be provided in a consistent place (e.g. setup.py or setup.cfg but not both) but if you review most setup.py scripts, you'll find what is simply a function call that passes metadata to classes that do everything you're describing and more. In more complex cases, you'll see the same function call, referencing user-supplied subclasses of internal commands that don't quite do what the author needs. I'll also agree that how this is done is not inuitive, nor well documented, but it works none-the-less. I appreciate that your suggestions are based on your experience with Distutils. It seems to me however, that your experience is limited and some of the suggestions you are proposing will impose severe limitations on those of us that deal with more diverse environments. mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From seefeld at sympatico.ca Wed May 19 14:10:09 2004 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed May 19 14:14:26 2004 Subject: [Distutils] thoughts on distutils 1 & 2 (addendum) In-Reply-To: References: Message-ID: <40ABA301.4030807@sympatico.ca> has wrote: > 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. As others already pointed out, what you suggest doesn't really change anything: 'setup.py' is just a facade to access distutils' functionality. building and installing *is* already controlled by two distinct objects ('commands'). > 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. what do you want to reuse that you can't right now ? As we all agree the 'build' class should be more polymorphic, i.e. it should be able to wrap your own build system for a component of the package (and that's one thing where DU1 lacks most IMO). However, in order for 'build' and 'install' to work smoothly together, they both have to respect some conventions, for example use some common metadata format to share information about the things to be installed. Regards, Stefan From hengist.podd at virgin.net Wed May 19 18:07:02 2004 From: hengist.podd at virgin.net (has) Date: Wed May 19 18:35:12 2004 Subject: [Distutils] thoughts on distutils 1 & 2 (addendum) In-Reply-To: <40ABA301.4030807@sympatico.ca> References: <40ABA301.4030807@sympatico.ca> Message-ID: Stefan Seefeld wrote: >>- 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. > >As others already pointed out, what you suggest doesn't really change >anything: 'setup.py' is just a facade to access distutils' functionality. >building and installing *is* already controlled by two distinct objects >('commands'). > >>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. > >what do you want to reuse that you can't right now ? The 'setup.py' [or whatever you want to call it] script. Reduce the amount of code the module developer needs to write. For simple modules and packages, this could (and should) be zero. >However, in order for 'build' and 'install' to work smoothly together, >they both have to respect some conventions, for example use some common >metadata format to share information about the things to be installed. Of course. My point is that some of this data shouldn't be in the setup scripts, and at least some of the rest should be automatically determined by the system rather than specified by the user (unless they need to override the automatics): - Put metadata (by which I mean information describing the module/package itself; its name, version, author, dependencies, etc) into a standard metadata file, e.g. meta.txt, within the package. - Put data/code used to build the distro into a build.py script. Put data/code used to install the distro into a install.py script. i.e. There should be a clear distinction made between information describing the module and information used merely in building/installing it (custom paths, framework bindings, etc). These are two very different things and should be handled accordingly. [Note: any time I say 'metadata' I'm referring to the former, not the latter.] With DU1, all this data is squidged into setup.py. This is suboptimal: it's not very convenient to read/edit, and there's some unnecessary duplication of metadata occurring over the build/install process as some of this data gets duplicated into PKG-INFO (which'd be unnecessary if it was put into a meta.txt file in the first place). Often the only unique information stored in setup.py is said 'metadata', which is really a suboptimal arrangement. (Plus stuff like sub-package names, which can and should be gotten rid of in most, if not all, cases.) Maybe a practical example'd help: Current: from distutils.core import setup setup(name = 'HTMLTemplate', version = '0.4.3', description = 'HTML templating engine.', author = 'HAS', author_email = '', # see Manual.txt url='http://freespace.virgin.net/hamish.sanderson/htmltemplate.html', license = 'LGPL', platforms = ['any'], long_description = 'HTMLTemplate converts XML/HTML/XHTML templates ...', py_modules = ['HTMLTemplate'], ) Suggested: - meta.txt version 0.4.3 description HTML templating engine author HAS author email see Manual.txt url http://freespace.virgin.net/hamish.sanderson/htmltemplate.html license LGPL platforms any long description HTMLTemplate converts XML/HTML/XHTML templates ... - install.py #!/usr/bin/env python from DU2 import install install() - build.py #!/usr/bin/env python from sys import argv from DU2 import build build(argv[1], omit='\.pyc$') Eliminating unnecessary duplication means the name shouldn't need to be declared more than once (i.e. the package folder name). The py_modules value is, by default, unnecessary. PKG-INFO is obsolete. README can be auto-generated (though I kinda wonder just how useful this really is and if it could be eliminated altogether). Both install.py and build.py are generic scripts: the former can be automatically inserted into the distro, the latter run from the shell as a standard build script. It'll still scale up just as well as DU1, so that's not a concern. The aim here is to handle the simplest and [presumably] most common cases more cleanly. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From slash at dotnetslash.net Wed May 19 19:11:01 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Wed May 19 19:11:06 2004 Subject: [Distutils] thoughts on distutils 1 & 2 (addendum) In-Reply-To: References: <40ABA301.4030807@sympatico.ca> Message-ID: <20040519231101.GB23303@dotnetslash.net> On Wed, May 19, 2004 at 11:07:02PM +0100, has wrote: > Stefan Seefeld wrote: > >what do you want to reuse that you can't right now ? > > The 'setup.py' [or whatever you want to call it] script. Reduce the > amount of code the module developer needs to write. For simple > modules and packages, this could (and should) be zero. [snip] > My point is that some of this data shouldn't be in the setup scripts, > and at least some of the rest should be automatically determined by > the system rather than specified by the user (unless they need to > override the automatics): I think, with proper metadata definitions standardized in setup.cfg, DU could be modified such that: from distutils import setup setup() would simply pull all it's information from the setup.cfg and go. That's _almost_ zero. I don't think you can get to absolute zero because somewhere the author has to specify the metadata. > - Put metadata (by which I mean information describing the > module/package itself; its name, version, author, dependencies, etc) > into a standard metadata file, e.g. meta.txt, within the package. That's what setup.cfg is. > - Put data/code used to build the distro into a build.py script. Put > data/code used to install the distro into a install.py script. Not necessary at all. > i.e. There should be a clear distinction made between information > describing the module and information used merely in > building/installing it (custom paths, framework bindings, etc). These > are two very different things and should be handled accordingly. > [Note: any time I say 'metadata' I'm referring to the former, not the > latter.] That would be nice, but if the package author requires "custom paths, framework bindings, etc." there's simply no way DU could guess where those come from so the author has to put them somewhere. The setup.cfg file (http://python.org/doc/current/dist/setup-config.html) already has different sections for the build and install metadata _if_ they are required. > With DU1, all this data is squidged into setup.py. This is > suboptimal: it's not very convenient to read/edit, and there's some > unnecessary duplication of metadata occurring over the build/install > process as some of this data gets duplicated into PKG-INFO (which'd > be unnecessary if it was put into a meta.txt file in the first place). setup.cfg == meta.txt The PKG-INFO file (iirc) is a(n extractable) subset of the setup.cfg metadata brought up in PEP 301 for the purpose of publishing package information to an "index server". It's not something that should have to be dealt with manually at all (again assuming we nail the metadata correctly). > Often the only unique information stored in setup.py is said > 'metadata', which is really a suboptimal arrangement. (Plus stuff > like sub-package names, which can and should be gotten rid of in > most, if not all, cases.) setup.py's dist process produces the PKG-INFO file, by combining the setup.py and setup.cfg metadata, although I'd still prefer to see setup.cfg be the "authoritative" metadata source so the "almost zero" setup.py concept would work with the author only having to maintain metadata in one place. (I think that's the force behind your argument, correct?) > Maybe a practical example'd help: [snip] I believe almost everything in your example is available through setup.cfg _today_. Your argument underscores the point that it is clearly not documented as such. By modifying setup() to search for any unspecified parameters in setup.cfg (which it almost does now; I think the only required arg is "name") doesn't that meet your goals? mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From hengist.podd at virgin.net Thu May 20 05:11:22 2004 From: hengist.podd at virgin.net (has) Date: Thu May 20 05:12:36 2004 Subject: [Distutils] thoughts on distutils 1 & 2 (addendum) In-Reply-To: References: <40ABA301.4030807@sympatico.ca> Message-ID: I wrote: >Eliminating unnecessary duplication means the name shouldn't need to >be declared more than once (i.e. the package folder name). The >py_modules value is, by default, unnecessary. PKG-INFO is obsolete. >README can be auto-generated (though I kinda wonder just how useful >this really is and if it could be eliminated altogether). Both >install.py and build.py are generic scripts: the former can be >automatically inserted into the distro, the latter run from the >shell as a standard build script. Oops, forgot to mention an obvious benefit for DU developers: eliminating a not insignificant quantity of code from DU. In particular, all module metadata handling (parsing/generating/verifying) duties can be handled by a much more useful general-purpose modulemetadata module in the standard library, to which DU would become just another client. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From seefeld at sympatico.ca Thu May 20 10:44:30 2004 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Thu May 20 10:48:53 2004 Subject: [Distutils] thoughts on distutils 1 & 2 (addendum) In-Reply-To: References: <40ABA301.4030807@sympatico.ca> Message-ID: <40ACC44E.8070502@sympatico.ca> has wrote: > Oops, forgot to mention an obvious benefit for DU developers: > eliminating a not insignificant quantity of code from DU. What code would that be ? In the simplest case setup.py is quite trivial. It's only when things get more complex and require 'manual' fine-tuning that this script (or other user-specific modules it loads) becomes large. I honestly find this approach quite scalable. > In particular, > all module metadata handling (parsing/generating/verifying) duties can > be handled by a much more useful general-purpose modulemetadata module > in the standard library, to which DU would become just another client. what is the scope of such a 'module metadata' module ? And who would use it beside distutils ? As I said earlier, I don't believe anything beside the already existing metadata (available through pythonic introspection) is needed or even useful for modules in general. What you seem to have in mind is important for *packages*, and that's exactly distutils' scope. Whenever I hear 'general purpose' a little warning light flashes in my mind... :-) Regards, Stefan From dwacdrd at dd.catv.ne.jp Thu May 20 16:12:07 2004 From: dwacdrd at dd.catv.ne.jp (Merrill Hartley) Date: Thu May 20 15:12:59 2004 Subject: [Distutils] does that position require a university degree? We'll sell you a REAL one! Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040520/ce0ec786/attachment.html From sympa at ens.fr Thu May 20 23:19:35 2004 From: sympa at ens.fr (SYMPA) Date: Thu May 20 23:22:00 2004 Subject: [Distutils] Results of your commands Message-ID: <200405210319.i4L3JZ7p052829@nef.ens.fr> > another pic, have fun! ... :-> Command not understood: ignoring end of message. No command found in message From wanglinxia at sina100.com Fri May 21 00:29:06 2004 From: wanglinxia at sina100.com (wanglinxia@sina100.com) Date: Fri May 21 00:25:49 2004 Subject: [Distutils] bring a professional look to your projects Message-ID: <200405210425.i4L4PeXl095724@mxzilla7.xs4all.nl> 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 From mats at laplaza.org Fri May 21 10:41:35 2004 From: mats at laplaza.org (Mats Wichmann) Date: Fri May 21 10:48:50 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> References: <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> Message-ID: <6.0.0.22.1.20040521083357.0275b008@mail.laplaza.org> At 11:22 AM 5/19/2004, Phillip J. Eby wrote: >At 10:22 AM 5/19/04 +0200, Floris van der Tak wrote: > >>Distutils was indeed part of python-devel, which is on the dvd, >>but is not part of the standard installation. >> >>Thanks for your help, Floris > >Somebody should probably provide feedback to the packager that they >shouldn't yank out arbitrary parts of the Python distribution into separate >(OS-level) packages. The standard library is the standard library: it >should not be subdivided. Mmmm, just about every distro is using the concept of splitting out packages you don't need if you're not a developer, but it's wrong in this case. I looked at some other distros and they're not doing this. If there's to be a python-devel package it could include the C-language headers and link-time python library, but not distutils (suse's package includes all of these). I'll drop someone I know there a note privately but this doesn't really constitute a formal bugreport. From seefeld at sympatico.ca Fri May 21 10:52:58 2004 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri May 21 10:57:18 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: <6.0.0.22.1.20040521083357.0275b008@mail.laplaza.org> References: <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> <6.0.0.22.1.20040521083357.0275b008@mail.laplaza.org> Message-ID: <40AE17CA.3060508@sympatico.ca> Mats Wichmann wrote: > Mmmm, just about every distro is using the concept of > splitting out packages you don't need if you're not > a developer, but it's wrong in this case. I looked That's a nice illustration for missing metainfo. As DU1 only deals with a single package, one would essentially have to provide two separate 'setup.py' files to build the 'user' and the 'devel' packages. As you point out, most distros make the distinction, so it might be a good idea for DU2 to provide support for that, such that 'python setup.py dist' will be able to generate both, , as well as -devel. Regards, Stefan From pje at telecommunity.com Fri May 21 11:03:34 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri May 21 11:04:28 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: <6.0.0.22.1.20040521083357.0275b008@mail.laplaza.org> References: <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> Message-ID: <5.1.1.6.0.20040521110229.03a4cec0@mail.telecommunity.com> At 08:41 AM 5/21/04 -0600, Mats Wichmann wrote: >At 11:22 AM 5/19/2004, Phillip J. Eby wrote: > >At 10:22 AM 5/19/04 +0200, Floris van der Tak wrote: > > > >>Distutils was indeed part of python-devel, which is on the dvd, > >>but is not part of the standard installation. > >> > >>Thanks for your help, Floris > > > >Somebody should probably provide feedback to the packager that they > >shouldn't yank out arbitrary parts of the Python distribution into separate > >(OS-level) packages. The standard library is the standard library: it > >should not be subdivided. > >Mmmm, just about every distro is using the concept of >splitting out packages you don't need if you're not >a developer, but it's wrong in this case. It's wrong in every case where the standard library is concerned. That is, after all, what "standard" means. :) From slash at dotnetslash.net Fri May 21 12:50:28 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Fri May 21 12:50:38 2004 Subject: [Distutils] distutils install probs on suse 9.0 In-Reply-To: <40AE17CA.3060508@sympatico.ca> References: <6.0.0.22.1.20040518071311.05c8edd8@mail.laplaza.org> <5.1.1.6.0.20040519131952.02f03bd0@home.unrestrained.com> <6.0.0.22.1.20040521083357.0275b008@mail.laplaza.org> <40AE17CA.3060508@sympatico.ca> Message-ID: <20040521165028.GA1970@dotnetslash.net> On Fri, May 21, 2004 at 10:52:58AM -0400, Stefan Seefeld wrote: > Mats Wichmann wrote: > > >Mmmm, just about every distro is using the concept of > >splitting out packages you don't need if you're not > >a developer, but it's wrong in this case. I looked > > That's a nice illustration for missing metainfo. > As DU1 only deals with a single package, one would essentially > have to provide two separate 'setup.py' files to build the > 'user' and the 'devel' packages. > As you point out, most distros make the distinction, > so it might be a good idea for DU2 to provide support > for that, such that 'python setup.py dist' will be able > to generate both, , as well as -devel. Agreed. I think DU2 needs a Package class (as in distributable package, not python package). Distribution can be abstracted a bit more to support managing multiple packages, with a default of 1 (the current behavior). mwa -- Mark W. Alexander slash@dotnetslash.net The contents of this message authored by Mark W. Alexander are released under the Creative Commons Attribution-NonCommercial license. Copyright of quoted materials are retained by the original author(s). http://creativecommons.org/licenses/by-nc/1.0/ From LISTSERV at COMPUTER.ORG Sun May 23 06:41:39 2004 From: LISTSERV at COMPUTER.ORG (L-Soft list server at IEEE Computer Society (1.8e)) Date: Sun May 23 06:41:43 2004 Subject: [Distutils] Message ("The distribution of your message dated Sun, 23...") Message-ID: 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. From pgsql-general at postgresql.org Mon May 24 08:33:01 2004 From: pgsql-general at postgresql.org (pgsql-general@postgresql.org) Date: Mon May 24 08:33:17 2004 Subject: [Distutils] Re: Question Message-ID: <200405241233.i4OCX0gb017775@mxzilla2.xs4all.nl> I have corrected your document. From wdsnvmwz at baer.rwth-aachen.de Wed May 26 20:01:53 2004 From: wdsnvmwz at baer.rwth-aachen.de (Gretchen Barrera) Date: Wed May 26 19:05:07 2004 Subject: [Distutils] better job Message-ID: <624F1E606FE65.6C7B8@24.68.42.247> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040527/4b388e51/attachment.html From kudgzma at livetosave.com Fri May 28 15:33:18 2004 From: kudgzma at livetosave.com (Amanda Gardner) Date: Fri May 28 14:27:05 2004 Subject: [Distutils] Huge savings on OEM Software. All brand names available now conceptual Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040528/5ce230b7/attachment.html From ubjmkyso at centrum.cz Sun May 30 14:22:24 2004 From: ubjmkyso at centrum.cz (Support portulaca) Date: Sun May 30 13:29:28 2004 Subject: [Distutils] G*A*Y FUC-k-K ONLY! fin affine isochronal apocalypse portulaca simulcast electron solicitude diphtheria cummings harbinger einstein rockefeller volt citrus yak berlin iridium distaff wong ecosystem travertine miami adonis deliquescent proscription automate methacrylate bend elton glance gratis ethereal Message-ID: - --- - FUKK ME GAYY - - -- -- FIRST G*A*Y FUC-k-K ONLY! http://www.fuckmegay.com/indexnem.html?k[7 From postmaster at mailsrv.aviointeriors.it Mon May 31 11:06:01 2004 From: postmaster at mailsrv.aviointeriors.it (postmaster@mailsrv.aviointeriors.it) Date: Mon May 31 11:09:47 2004 Subject: [Distutils] VIRUS IN YOUR MAIL Message-ID: <20040531150601.4995EC8409@mailsrv.aviointeriors.it> V I R U S A L E R T Our viruschecker found the I-Worm.NetSky.r virus(es) in your email to the following recipient(s): -> catfor@aviointeriors.it Please check your system for viruses, or ask your system administrator to do so. For your reference, here are the headers from your email: ------------------------- BEGIN HEADERS ----------------------------- Received: from aviointeriors.it (adsl110.12.cyb.it [195.191.12.110]) by mailsrv.aviointeriors.it (Postfix) with ESMTP id 958C6C8404 for ; Mon, 31 May 2004 17:05:57 +0200 (CEST) From: distutils-sig@python.org To: catfor@aviointeriors.it Subject: Mail Delivery failure (catfor@aviointeriors.it) Date: Mon, 31 May 2004 17:28:57 +0200 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_001B_01C0CA81.7B015D10" X-Priority: 1 X-MSMail-Priority: High Message-Id: <20040531150557.958C6C8404@mailsrv.aviointeriors.it> -------------------------- END HEADERS ------------------------------ From Darrell at ranmamail.com Mon May 31 17:43:10 2004 From: Darrell at ranmamail.com (Tamika Flores) Date: Mon May 31 16:44:51 2004 Subject: [Distutils] Get your hands on the leading software products at only a fraction of the costs! ; -) monic Message-ID: Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 10716 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040531/2cc4bb6f/attachment.gif