Rap Battle

From software at rocscience.com Mon Mar 1 02:25:13 2004 From: software at rocscience.com (software@rocscience.com) Date: Mon Mar 1 02:25:19 2004 Subject: [Distutils] hello Message-ID: greetings -------------- next part -------------- A non-text attachment was scrubbed... Name: disco.zip Type: application/x-zip-compressed Size: 0 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040301/e0fba174/disco.bin From tcsh-bugs-bounces at mx.gw.com Tue Mar 2 07:55:35 2004 From: tcsh-bugs-bounces at mx.gw.com (tcsh-bugs-bounces@mx.gw.com) Date: Tue Mar 2 07:55:40 2004 Subject: [Distutils] Your message to Tcsh-Bugs awaits moderator approval Message-ID: Your mail to 'Tcsh-Bugs' with the subject something for you 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. If you would like to cancel this posting, please visit the following URL: http://mx.gw.com/mailman/confirm/tcsh-bugs/5778b04546fb0489f06a79d825e3b968b620336a From jonathan at hotmail.com Tue Mar 2 14:19:54 2004 From: jonathan at hotmail.com (Jonathan) Date: Tue Mar 2 14:23:03 2004 Subject: [Distutils] asdf Message-ID: asdf From nerdgirl at bastard.com Wed Mar 3 08:09:51 2004 From: nerdgirl at bastard.com (mabel weakness) Date: Wed Mar 3 08:10:06 2004 Subject: [Distutils] Rap Batle Message-ID: <200403031310.i23DA1xW095076@mxzilla4.xs4all.nl> Rap Battle

Yo limp dizzle, I got the salooshin to yer bodies palooshin'. Take one dose of thizz, give that ho a kizz, drop yo draws, she'll luv how hard it izz. She be breaking down your door, begging for more. Spreadin' them legs like a dirty wh*re...

- Life just seems to flow with Ciliazz. Don't want any dis, then flow owt with our lizt.

World famous rapper, Shawtie Flave of Dawty Soüth Reckardz

From noreply at python.org Wed Mar 3 11:42:58 2004 From: noreply at python.org (noreply@python.org) Date: Wed Mar 3 11:42:59 2004 Subject: [Distutils] Warning about your e-mail account. Message-ID: Dear user of Python.org gateway e-mail server, Your e-mail account will be disabled because of improper using in next three days, if you are still wishing to use it, please, resign your account information. Advanced details can be found in attached file. Attached file protected with the password for security reasons. Password is 10246. Kind regards, The Python.org team http://www.python.org -------------- next part -------------- A non-text attachment was scrubbed... Name: Document.zip Type: application/octet-stream Size: 12420 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040303/bb372bf9/Document.obj From anthony at computronix.com Wed Mar 3 12:41:58 2004 From: anthony at computronix.com (Anthony Tuininga) Date: Wed Mar 3 14:13:13 2004 Subject: [Distutils] Warning about your e-mail account. In-Reply-To: References: Message-ID: <1078335718.3121.30.camel@chl0263.edmonton.computronix.com> Is this for real? It looks like SPAM and an attempt to spread a virus but maybe I'm just too paranoid? On Wed, 2004-03-03 at 09:42, noreply@python.org wrote: > Dear user of Python.org gateway e-mail server, > > Your e-mail account will be disabled because of improper using in next > three days, if you are still wishing to use it, please, resign your > account information. > > Advanced details can be found in attached file. > > Attached file protected with the password for security reasons. Password is 10246. > > Kind regards, > The Python.org team http://www.python.org > > > ______________________________________________________________________ > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Anthony Tuininga anthony@computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com From anthony.seward at ieee.org Wed Mar 3 14:45:33 2004 From: anthony.seward at ieee.org (Anthony Joseph Seward) Date: Wed Mar 3 14:45:58 2004 Subject: [Distutils] Warning about your e-mail account. In-Reply-To: <1078335718.3121.30.camel@chl0263.edmonton.computronix.com> References: <1078335718.3121.30.camel@chl0263.edmonton.computronix.com> Message-ID: <1078343132.3490.36.camel@sonylap1> Most likely SPAM. IEEE just sent out a warning to all members with ieee.org e-mail addresses that here is a similar trojan attack pretending to come from them. Tony On Wed, 2004-03-03 at 10:41, Anthony Tuininga wrote: > Is this for real? It looks like SPAM and an attempt to spread a virus > but maybe I'm just too paranoid? > > On Wed, 2004-03-03 at 09:42, noreply@python.org wrote: > > Dear user of Python.org gateway e-mail server, > > > > Your e-mail account will be disabled because of improper using in next > > three days, if you are still wishing to use it, please, resign your > > account information. > > > > Advanced details can be found in attached file. > > > > Attached file protected with the password for security reasons. Password is 10246. > > > > Kind regards, > > The Python.org team http://www.python.org > > > > > > ______________________________________________________________________ > > _______________________________________________ > > Distutils-SIG maillist - Distutils-SIG@python.org > > http://mail.python.org/mailman/listinfo/distutils-sig -- Anthony Joseph Seward From anthony at interlink.com.au Wed Mar 3 18:52:56 2004 From: anthony at interlink.com.au (Anthony Baxter) Date: Wed Mar 3 18:53:13 2004 Subject: [Distutils] Warning about your e-mail account. In-Reply-To: <1078335718.3121.30.camel@chl0263.edmonton.computronix.com> References: <1078335718.3121.30.camel@chl0263.edmonton.computronix.com> Message-ID: <40466FD8.4010103@interlink.com.au> Anthony Tuininga wrote: > Is this for real? It looks like SPAM and an attempt to spread a virus > but maybe I'm just too paranoid? It's a worm. We've seen a bunch of them go through the email servers at work. -- Anthony Baxter It's never too late to have a happy childhood. From scott.l.miller at compaq.com Thu Mar 4 04:55:56 2004 From: scott.l.miller at compaq.com (scott.l.miller@compaq.com) Date: Thu Mar 4 09:30:21 2004 Subject: [Distutils] something for you Message-ID: <200403040956.i249uB008839@mail6.sony.co.jp> take it easy -------------- next part -------------- ------------------ Virus Warning Message (on the network) msg.com is removed from here because it contains a virus. --------------------------------------------------------- -------------- next part -------------- ------------------ Virus Warning Message (on the network) Found virus WORM_NETSKY.B in file msg.com The file is deleted. Therefore we removed the attachment-file by Mail Server and sent the message to you. (Japanese) ???????????????????????????????? ???????????????????????????????? ????????? --------------------------------------------------------- From junk at realityx.net Thu Mar 4 21:56:10 2004 From: junk at realityx.net (junk spam) Date: Thu Mar 4 21:56:22 2004 Subject: [Distutils] automated response Message-ID: <10403050356.AA150744717@realityx.net> Please stop spamming.. This is an automated reply.. From cyberopoe at hotmail.com Sat Mar 6 15:00:05 2004 From: cyberopoe at hotmail.com (Cyberopoe) Date: Sat Mar 6 22:16:09 2004 Subject: [Distutils] my scream :( In-Reply-To: <5BK5B4BGE5CC7ID1@python.org> References: <5BK5B4BGE5CC7ID1@python.org> Message-ID: Cialis IsA NewImpotenceDrug. Cialis is in a class of medications known as PDE-5Inhibitors, which are used to treat MaleImpotence. Up to 86% of patients WhoTakeCialis experience an improvement in their erections. CialisActs in the SameWay As Viagr. YouGainE-rections faster and easier with Cialis. WhyWe? - NoPrescriptionRequired - FreeConsultations - WorldwideShipping - SatisfactionGuaranteed - MoneyBackGuarantee http://15.pharmaheaven.com/15/ From pje at telecommunity.com Sun Mar 7 17:38:21 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Sun Mar 7 17:33:08 2004 Subject: [Distutils] "setuptools" package preview Message-ID: <5.1.0.14.0.20040307172057.01f2ee40@mail.telecommunity.com> I'm working on a set of distutils enhancements called "setuptools". The "setuptools" extend the base Distribution class with the ability to do: * feature management -- you can define subsets of a distribution as "features" that can be enabled or disabled via '--with-X' and '--without-X' options to 'setup.py'. Features can (recursively) depend on other features, and be included or excluded by default. (Their inclusion or exclusion affects all commands, as the relevant packages/modules/data/scripts/whatever are added or removed just after command line arguments are parsed.) * package data installation -- you can specify filenames or globs to be searched for in package source directories, for installation alongside the package .py files. All without munging the 'install_data' command or manually copying files, and the data files are correctly included in the 'get_outputs()' manifest for all the distutils features that depend on knowing what files were copied. * 'test' command -- optionally run a user-specified or 'setup.py'-specified test suite via the 'unittest' module. * Packages and modules can be simultaneously specified as arguments to 'setuptools.setup()', unlike the standard distutils 'setup()'. The above features are all fully implemented and documented via docstrings, and the majority of them are covered by an extensive unit test suite. "setuptools" uses itself for its own 'setup.py', in order to enable the 'test' command to run its built-in unit tests. The purpose of "setuptools" is to collect commonly useful distutils enhancements for large or complex packages like Zope X3 and PEAK. It's also intended to be the starting point for developing simple installer-side dependency support, as described/proposed at: http://www.python.org/cgi-bin/moinmoin/DistutilsDependencies Finally, I also intend to add some type of general-purpose documentation build and install facilities, to replace the rather hacky documentation support in my current setup scripts. At this point, the package isn't quite ready for general release, as it doesn't include documentation beyond docstrings, and of course the dependency and documentation features aren't written yet. But I believe it is ready for feedback from interested parties such as PyCon sprinters, and people who are undertaking complex distutils projects. I'm interested in your comments, especially as they may relate to the viability of eventually merging setuptools into a "Distutils 2.0" (or maybe "1.5"). Setuptools is specifically laid out to match the package layout and naming conventions of the distutils in order to facilitate such porting. You can currently find the setuptools CVS at: http://cvs.eby-sarna.com/setuptools/ although there has been some discussion about moving it to the Zope X3 CVS in the near future to facilitate the coming sprint, and other contributions. Please follow up with discussion to the distutils-sig mailing list. Thanks. From pje at telecommunity.com Mon Mar 8 11:41:50 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon Mar 8 11:36:45 2004 Subject: [Distutils] Re: PEP 262 In-Reply-To: <20040308140436.GA15744@rogue.amk.ca> References: <5.1.0.14.0.20040307215832.01eab330@mail.telecommunity.com> <5.1.0.14.0.20040307215832.01eab330@mail.telecommunity.com> Message-ID: <5.1.0.14.0.20040308112416.02610de0@mail.telecommunity.com> At 09:04 AM 3/8/04 -0500, A.M. Kuchling wrote: >On Sun, Mar 07, 2004 at 10:26:38PM -0500, Phillip J. Eby wrote: > > Hi Andrew. I was looking over PEP 262 today for possible > implementation in > > "setuptools", and I had a few questions and comments. > >You should have sent this post to the catalog-sig or distutils-sig, because >it raises some interesting issues. > > > 1) be called 'install-db', to avoid conflict with a package name > >Good idea; PEP updated. > > > 2) be potentially present on every directory in sys.path, with the > contents > > merged in sys.path order. This would allow home-directory or other > > alternate-location installs to work, and ease the process of a distutils > > install command writing the file. > >Hm; for some reason I find the idea of multiple databases disturbing; would >it be too confusing and error-prone? On the other hand, it does mean that >package manager tools can take into account packages that a user has >privately installed, which is a nice feature. On balance I suppose it's a >good idea. > >Ooh, but what does setup.py do if it's told to install packages to a >directory not on sys.path? Does it write an install-db directory to the >directory it's told to write to, or does it do nothing? The directory where it's installing packages to. Also, for purposes of uninstallation, it should include that installation directory on the list of directories scanned for package installation info. This all means that the installdb API needs to be able to be told what directories to search, perhaps with a default of sys.path. In a manner analogous to the way modules can shadow each other on sys.path, distributions found earlier in the directory searches should shadow later distributions with the same name. (This prevents confusion between a user's local version of a distribution, and the system-supplied version.) > > Next, I'd like to ask if it's okay to have the minimum contents of a > > package file be PKG-INFO FILES instead of also requiring PROVIDES and > > REQUIRES. The latter two seem a bit premature for > >PROVIDES and REQUIRES can simply be left empty, though. I can weaken the >language in this section a bit. > > > * Should the package-database file itself be included in the files > > list? (I would think yes, but of course it can't contain its own > checksum!) > >Does it really matter? The only case I can think where this matters is >removing a package, where you could just read all of the files listed in the >database and delete them. But the code implementing this will be in the >InstallationDatabase class, which will already have the filename of the >database file. In short, I don't think this really matters. Do you have a >use case for including it? If you use 'setup.py install --result=somefile', the distribution's information file should be included (for compatibility with external packaging tools that use --result). So, that means the 'install' command object should have it listed in its 'get_outputs()'. But, presumably the list that goes into the file is going to *come* from 'get_outputs()'. So, it seems like the list would include the file itself, if that makes sense. > > * The spec says that checksums of .pyc/.pyo files should not have their > > checksums stored, but does not say *how* to not store them. By omitting > > the field? By placing 'unknown' there? > >I was thinking that the field would simply be '-'. It could be omitted, but >then if we ever add another column there will be problems. PEP updated to >specify "-". Come to think of it, why *shouldn't* those files be verified as to checksum? Is it simply because they contain an internal timestamp? >Hey, this raises another issue; should we guarantee the format of >installation databases remains compatible across Python versions, or is it >subject to arbitrary change? I would think it needs to be guaranteed. If there's a change, it would need to be by adding a new section name like 'FILES2' for the new format. In practice, though, FILES is extensible via additional columns, and the metadata section is extensible via adding new header lines. So, all in all, the format is reasonably future-proof, at least for the critical sections. > > * Are there any legal or other issues regarding deployment of SHA1? I'm > >No, SHA just does hashing, not encryption, so there are no problems with its >inclusion in Python. > > > Finally, there's a bit of a terminology issue. I think that the term > > "package" should be used for Python packages exclusively, using perhaps > > "distribution" to refer to an installed unit. So, instead of looking up a > > "package", you would look up a "distribution". Currently, the use of > > "package" in the PEP is ambiguous, making it difficult to understand in > > parts. > >PEP updated. > > > Anyway, apart from these issues/questions, I think it should be possible > > for me to move forward with an implementation, possibly complete with a > > facility to uninstall/upgrade/verify, although I can't guarantee *when* > >Note that there's already an implementation in nondist/sandbox/pep262 in >CVS, though I don't remember how complete it was. I'm planning to dust it >off before PyCon. Ah. If I'd known where it was, I'd have UTSL'ed to see if it answered any of these questions. I'll take a look at it when I get a chance. Another spec question: is there a blank line after the line listing the sections? Can there be one? Are sections separated by a *single* blank line, or can there be more than one blank line between them? From fdrake at acm.org Mon Mar 8 15:21:02 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Mar 8 15:21:13 2004 Subject: [Distutils] "setuptools" package preview In-Reply-To: <5.1.0.14.0.20040307172057.01f2ee40@mail.telecommunity.com> References: <5.1.0.14.0.20040307172057.01f2ee40@mail.telecommunity.com> Message-ID: <200403081521.02214.fdrake@acm.org> On Sunday 07 March 2004 05:38 pm, Phillip J. Eby wrote: > * feature management -- you can define subsets of a distribution as > "features" that can be enabled or disabled via '--with-X' and > '--without-X' options to 'setup.py'. Features can (recursively) depend on > other features, and be included or excluded by default. (Their inclusion > or exclusion affects all commands, as the relevant > packages/modules/data/scripts/whatever are added or removed just after > command line arguments are parsed.) This seems nice, though I'm not sure I actually have an immediate need for this. Do you expect to use this to provide sub-packages that would only be installed if they weren't installed by some other distribution? > * package data installation -- you can specify filenames or globs to be > searched for in package source directories, for installation alongside the > package .py files. All without munging the 'install_data' command or > manually copying files, and the data files are correctly included in the > 'get_outputs()' manifest for all the distutils features that depend on > knowing what files were copied. I think this should be integrated directly into distutils as soon as possible. I looked at your implementation as of Friday, and it made sense to me. > * 'test' command -- optionally run a user-specified or > 'setup.py'-specified test suite via the 'unittest' module. People have been wanting this in distutils for a while, but I don't think people agree much on how unit tests should be run (how to write them isn't very well agreed on either). I suspect it's premature to integrate this into the main distutils at this time. > * Packages and modules can be simultaneously specified as arguments to > 'setuptools.setup()', unlike the standard distutils 'setup()'. Yes! This is goodness, and has been long requested. This should go directly into distutils. > At this point, the package isn't quite ready for general release, as it > doesn't include documentation beyond docstrings, and of course the > dependency and documentation features aren't written yet. But I believe If you package up the two features I care most about as a patch to distutils, I'll happily write the documentation for them. ;-) I like the idea of having an extended distutils for advanced packaging, but I don't see that such a beast would need to be integrated into distutils whole hog, or that it makes sense to do so. We should be able to pick the features that belong in the distutils core independently of what an extended package supports. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From administrator at mail.niac.com Mon Mar 8 15:28:25 2004 From: administrator at mail.niac.com (administrator@mail.niac.com) Date: Mon Mar 8 15:28:29 2004 Subject: [Distutils] Virus Warning Message-ID: <200403082028.AJT00356@mail.niac.com> The message you emailed to 034014ac, dated 03/08/04 15:28:25, contains the W32/Netsky-C virus in the violence_wife.zip attachment. Action taken: deleted From pje at telecommunity.com Mon Mar 8 16:09:02 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Mon Mar 8 16:04:52 2004 Subject: [Distutils] "setuptools" package preview In-Reply-To: <200403081521.02214.fdrake@acm.org> References: <5.1.0.14.0.20040307172057.01f2ee40@mail.telecommunity.com> <5.1.0.14.0.20040307172057.01f2ee40@mail.telecommunity.com> Message-ID: <5.1.0.14.0.20040308154340.03969730@mail.telecommunity.com> At 03:21 PM 3/8/04 -0500, Fred L. Drake, Jr. wrote: >On Sunday 07 March 2004 05:38 pm, Phillip J. Eby wrote: > > * feature management -- you can define subsets of a distribution as > > "features" that can be enabled or disabled via '--with-X' and > > '--without-X' options to 'setup.py'. Features can (recursively) depend on > > other features, and be included or excluded by default. (Their inclusion > > or exclusion affects all commands, as the relevant > > packages/modules/data/scripts/whatever are added or removed just after > > command line arguments are parsed.) > >This seems nice, though I'm not sure I actually have an immediate need for >this. Do you expect to use this to provide sub-packages that would only be >installed if they weren't installed by some other distribution? Actually, I intended that facility to support Zope X3 automatic package assembly, among other things. So, you could say for example that 'zope.publisher' depends on 'zope.interface', in order to be able to automatically assemble a subset distribution. I was envisioning you using it as the output of your "scan the packages for setup metadata" tool. That is, you'd create Feature instances for the packages, including their extensions and dependencies on other packages. Then, you could do e.g.: python setup.py --with-zope-publisher dist to build distributions that include zope.publisher and its dependencies from the Zope source tree. (Of course, you might also have some "logical" features that do nothing but list some "physical" features representing packages, rather than defining packages as features. Also, if you create features with the 'optional=False' argument, they do not get '--with/--without' options created, so you can use features as an internal organizing mechanism without exposing them to the user.) What I'm using features for in PEAK is to include optional things like a FastCGI module, a 'uuidgen' module that's only used on certain BSD platforms, and so on. And in PyProtocols, it's used to allow people to do: python setup.py --without-speedups install if they don't have a C compiler. > > * 'test' command -- optionally run a user-specified or > > 'setup.py'-specified test suite via the 'unittest' module. > >People have been wanting this in distutils for a while, but I don't think >people agree much on how unit tests should be run (how to write them isn't >very well agreed on either). I suspect it's premature to integrate this into >the main distutils at this time. Hm. What if I move the current implementation to a 'unittest' command, and make the suite argument 'unittest_suite'? Then, I could add a new 'test' command with 'unittest' as a subcommand, and the result would then be extensible for other forms of testing. > > At this point, the package isn't quite ready for general release, as it > > doesn't include documentation beyond docstrings, and of course the > > dependency and documentation features aren't written yet. But I believe > >If you package up the two features I care most about as a patch to distutils, >I'll happily write the documentation for them. ;-) As it happens, both of those features are implemented by the 'build_py' command, found in 'setuptools.command.build_py', and corresponding to 'distutils.command.build_py'. The only other bit you need is to add: self.package_data = {} to the beginning of 'distutils.dist.Distribution.__init__()', to allow passing 'package_data' to setup(). There are a couple of tricky bits to this, though. First, my 'build_py' makes superclass calls to the original 'build_py', so you'd need to move the old 'get_outputs()' implementation to another method name, then call that where I call the original 'build_py.get_outputs()'. I'll then have to have setuptools check whether that extra method name exists, and if so, have it use distutils' 'build_py' command instead of its own (for forward compatibility w/Python 2.4). From pje at telecommunity.com Tue Mar 9 18:57:49 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Tue Mar 9 18:52:36 2004 Subject: [Distutils] Unravelling installation schemes Message-ID: <5.1.0.14.0.20040309180722.03024ec0@mail.telecommunity.com> I'm working on implementing distutils dependencies, as described at: http://www.python.org/cgi-bin/moinmoin/DistutilsDependencies and I've run into a bit of a hitch. In order to run dependencies' setup scripts, I need to be able to pass along command line options from the parent setup script. But, it's not quite that simple. The distutils framework allows people to specify quite a few options at multiple levels. For example, you can specify a different C compiler to the build_lib and build_ext commands, and a third one to the build command itself! Next, there's path munging and alternate installation schemes, along with the 'extra_path' support, install-lib overriding purelib and platlib, the distribution name embedded in the install-headers path, and so on. My brain is approaching critical mass for explosion. :) Now, add to this some additional requirements that are specific to dependency management. I need to know where stuff is being installed, so that when I check for the existence of a dependency, I'm not fooled by it not being on sys.path currently. And, what if a dependency exists on extra_path? [sob, sniff] I guess I'm beginning to see why nobody else has tackled this up to now. :) Of course, for maybe half the installs it would suffice to just run 'setup.py install' on the dependencies. For about half of the remaining situations, it would probably suffice to just pass along whatever options were specified on the parent setup script's command line, verbatim. It's the remaining scenarios that are tough: * Some joker uses a relative path on the command line (could fix, if we know which arguments are directories) * Non-build/non-install commands (could maybe fix by only copying options for build, install, and subcommands thereof) * Somebody uses an explicit --install-lib or install_lib --install-dir (fixable, but it could screw things up if they really should've been specifying platlib or purelib or one of the higher-level options) * Somebody uses an explicit install --install-headers or install_headers --install-dir (aaagh!) So far, I'm thinking that about the only thing to do is: 1. Go through all the command-line options for install, build, and their subcommands 2. If *any* '--install-X' option exists apart from 'install-base' or 'install-platbase', raise holy heck and stop the gravy train when trying to install dependencies. Ask the user to either change their options, or to manually run the child setup with appropriate options, specifying where it is and what to do. 3. Only pass recognized-to-be safe options from build and its subcommands. (Which is probably going to equate to just the compiler option, include-) Fix up directory options from the install command to be absolute. Barf if an inplace build_ext was specified. 4. Don't use any options that came from config files. If it was a global config, it'll apply to the child setup automatically. If it came from the local setup.cfg, it *shouldn't* apply to the child. Whew. So here's the thing... am I making this too hard? Is there a better way to deal with options to child setups? I look at all the zillions of options to the individual commands, and I think about when and why I might specify those options, I think I mostly *wouldn't* want them passing through to the child setups. Maybe the simplest thing to do would be to make a list of "safe" command-line options that will be passed to children, and issue warnings for the rest? Or maybe stop the build if any options would be ignored, unless a "go ahead anyway" option is given? What do y'all think? I guess I'm now leaning towards that last option... simply dump out on-screen all the command-line arguments that aren't safe, and show what *would* be passed to the child setup, and show what arguments would be needed to provide a command line that will force the build to proceed anyway, and also how to run the child setup manually (since the target will have already been downloaded and extracted to the temporary directory). This won't address complex installation options, but then, if somebody has complex installation options, they can probably deal with a little complexity for installing the dependencies, I guess. There are a few other issues floating about, mostly to do with sys.path, .pth files, and installation to locations other than site-packages. But I think I'll leave those thoughts to another post. :) From slash at dotnetslash.net Tue Mar 9 20:44:58 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Tue Mar 9 20:45:01 2004 Subject: [Distutils] Unravelling installation schemes In-Reply-To: <5.1.0.14.0.20040309180722.03024ec0@mail.telecommunity.com> References: <5.1.0.14.0.20040309180722.03024ec0@mail.telecommunity.com> Message-ID: <20040310014457.GA18612@dotnetslash.net> On Tue, Mar 09, 2004 at 06:57:49PM -0500, Phillip J. Eby wrote: > I guess I'm beginning to see why nobody else has tackled this up to now. :) My $.02 is, Distutils can take one of 2 forms. It can be automake/autoconf for Python and everyone can install from source, or it can be a package manager. The battle you're fighting seems to me to be from trying to make it do both. If Distutils can make binary packages for most package managers, and it can be extended to include "Provides" and "Requires" in the meta-data, then any OS's native package manager should have all the information it needs to do the right thing at install time. > Of course, for maybe half the installs it would suffice to just run > 'setup.py install' on the dependencies. For about half of the remaining > situations, it would probably suffice to just pass along whatever options > were specified on the parent setup script's command line, verbatim. Why does everyone seem to think that the prefered method of Distutils package installations is "setup.py install"? What's the point of providing bdist_* commands if we're going to perpetualy re-inforce the "setup.py install" mindset? I'm not trying to be confrontational here, but do we seriously expect everyone who wants to install Distutils packages to have a compiler suite in case a package has C extensions? Even without C extensions, I suspect you can rule out most Windows users by just telling them to "setup.py install". You'll be lucky if you can get them to listen long enough when they ask you to explain how to pass "install" as an option when they click the setup.py icon. I really, really, think Distutils should _produce_binary_packages. For as many platforms and package managers as possible, with as much meta-data as each package manager supports. Then we can just let the package managers worry about dependencies and not re-invent another wheel. > It's the remaining scenarios that are tough: > > * Some joker uses a relative path on the command line (could fix, if we > know which arguments are directories) > > * Non-build/non-install commands (could maybe fix by only copying options > for build, install, and subcommands thereof) > > * Somebody uses an explicit --install-lib or install_lib --install-dir > (fixable, but it could screw things up if they really should've been > specifying platlib or purelib or one of the higher-level options) > > * Somebody uses an explicit install --install-headers or install_headers > --install-dir (aaagh!) No matter what you do, there will be people who are simply not good at packaging software. Where Distutils shines is with a minimal amount of configuration "setup.py bdist_whatever" will produce a binary usable by anyone with the whatever package manager, even if the developer created their setup.py on a completely different platform. This is the real magic. It's what distinguishes Distutils from CPAN.* You are taking quite a leap when you talk about supporting multiple binary packages from a single source package. I started by abstracting a generic bdist_packager that simply managed the PEP 241 meta-data so bdist_commands could rely on it for metadata information. Subpackages was an extension I never got around to. My point is, _nothing_ you can code will save a bad packager from themself. The penalty for producing bad packages is that no one uses them because they're a pain to install. OTOH, Distutils should do everything it can to make it simple to package a module directories into multiple inter-dependent components so it takes reall effort to screw up the packaging. > There are a few other issues floating about, mostly to do with sys.path, > .pth files, and installation to locations other than site-packages. But I > think I'll leave those thoughts to another post. :) Personal whine :( I solved these issues on both Solaris and HP-UX by making bdist_commands that produced packages that were relocatable by the native package manager based on where the python installation was installed on the target and any other criteria required. I'm sorry, I _still_ waiting on my employer's approval to (re)submit them, but I strongly believe _that's_ the approach to take. Using native package managers intelligience and pre and post install scripts lets the person _installing_ the package make these decisions. That person is the REAL Distutils "customer". Helping developers make better packages is simply the most effective way to improve the end user (package installer) experience. When Distutils generated packages are universally available via apt/yum repositories, on the sunfreeware.com site and the HP Porting Archive Center, _that_ will be day I consider Distutils a true success. *I know... People point to the popularity of CPAN, which has NO integration with package managers. My point exactly! If you rebuild a box, your package manager knows everything that needs to be installed _except_ stuff CPAN brought down. Please, let's not do this with Distutils.... 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 Paul.Moore at atosorigin.com Wed Mar 10 01:53:58 2004 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Wed Mar 10 01:53:59 2004 Subject: [Distutils] Unravelling installation schemes Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C09D5B@UKDCX001.uk.int.atosorigin.com> From: Mark W. Alexander > Why does everyone seem to think that the prefered method of Distutils > package installations is "setup.py install"? FWIW, I agree. On Windows I *always* do setup.py bdist_wininst and then run the generated installer. This gives me an uninstall option, which "raw" distutils doesn't. This is *not* a plea for uninstall capability in distutils :-) Paul. From pje at telecommunity.com Wed Mar 10 11:29:58 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 10 11:24:40 2004 Subject: [Distutils] Unravelling installation schemes In-Reply-To: <20040310014457.GA18612@dotnetslash.net> References: <5.1.0.14.0.20040309180722.03024ec0@mail.telecommunity.com> <5.1.0.14.0.20040309180722.03024ec0@mail.telecommunity.com> Message-ID: <5.1.0.14.0.20040310111130.02141270@mail.telecommunity.com> At 08:44 PM 3/9/04 -0500, Mark W. Alexander wrote: >On Tue, Mar 09, 2004 at 06:57:49PM -0500, Phillip J. Eby wrote: > > I guess I'm beginning to see why nobody else has tackled this up to > now. :) > >My $.02 is, Distutils can take one of 2 forms. It can be >automake/autoconf for Python and everyone can install from source, or it >can be a package manager. The battle you're fighting seems to me to be >from trying to make it do both. Actually, it has a lot more to do with the path munging that the 'install' command does, which doesn't preserve a lot of the information in question, coupled with the fact that I'm producing a separate package, rather than hacking the distutils source directly. >If Distutils can make binary packages for most package managers, and it >can be extended to include "Provides" and "Requires" in the meta-data, >then any OS's native package manager should have all the information it >needs to do the right thing at install time. Well, it sounds like you have more experience with those package managers than I do, so it would be helpful if you could lay out a plan for this with sufficient detail to at least allow me to contemplate implementing it. > > Of course, for maybe half the installs it would suffice to just run > > 'setup.py install' on the dependencies. For about half of the remaining > > situations, it would probably suffice to just pass along whatever options > > were specified on the parent setup script's command line, verbatim. > >Why does everyone seem to think that the prefered method of Distutils >package installations is "setup.py install"? Er, perhaps because they prefer it? :) I know I do. > What's the point of >providing bdist_* commands if we're going to perpetualy re-inforce the >"setup.py install" mindset? I'm not trying to be confrontational here, >but do we seriously expect everyone who wants to install Distutils >packages to have a compiler suite in case a package has C extensions? That's why I want the dependency system to support installing binary packages as dependencies, at least on Windows. >Even without C extensions, I suspect you can rule out most Windows users >by just telling them to "setup.py install". You'll be lucky if you can >get them to listen long enough when they ask you to explain how to pass >"install" as an option when they click the setup.py icon. Uh, wouldn't you be supplying your application to those people as a py2exe or other installable with all its dependencies self-contained? >I really, really, think Distutils should _produce_binary_packages. For >as many platforms and package managers as possible, with as much >meta-data as each package manager supports. Fantastic, so we can count on your support for specifying what metadata is needed in a way that will work with all these package managers? :) Keep in mind that many developers don't have a clue about these package managers, perhaps not even the one for the system they use! If distutils requires the developer to understand every packaging system in order to release a package, it's useless. However, if all the information needed for packaging can be described in setup.cfg, I imagine most developers would accept patches from people with packaging tool experience to add metadata for the various package managers. Even then, I'm not sure how workable it is, given that dependencies would now need to include many more URLs for where to get all the differently-packaged versions of the packages. From theller at python.net Wed Mar 10 13:13:34 2004 From: theller at python.net (Thomas Heller) Date: Wed Mar 10 13:13:43 2004 Subject: [Distutils] Unravelling installation schemes In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8802C09D5B@UKDCX001.uk.int.atosorigin.com> (Paul Moore's message of "Wed, 10 Mar 2004 06:53:58 -0000") References: <16E1010E4581B049ABC51D4975CEDB8802C09D5B@UKDCX001.uk.int.atosorigin.com> Message-ID: "Moore, Paul" writes: > From: Mark W. Alexander >> Why does everyone seem to think that the prefered method of Distutils >> package installations is "setup.py install"? > > FWIW, I agree. On Windows I *always* do setup.py bdist_wininst and then > run the generated installer. This gives me an uninstall option, which > "raw" distutils doesn't. For this I have a recipe in the Python Cookbook (probably must be brought up to date for Python 2.3) which automates this: You can create a shortcut on the desktop where you can drag source distributions in .zip or .tar.gz format, the bdist_wininst installer is then built and run. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/117248 Thomas From pje at telecommunity.com Wed Mar 10 13:23:08 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 10 13:17:51 2004 Subject: [Distutils] Unravelling installation schemes In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8802C09D5B@UKDCX001.uk.int.a tosorigin.com> Message-ID: <5.1.0.14.0.20040310132050.02681800@mail.telecommunity.com> At 06:53 AM 3/10/04 +0000, Moore, Paul wrote: >From: Mark W. Alexander > > Why does everyone seem to think that the prefered method of Distutils > > package installations is "setup.py install"? > >FWIW, I agree. On Windows I *always* do setup.py bdist_wininst and then >run the generated installer. This gives me an uninstall option, which >"raw" distutils doesn't. Clever idea. I think I'll try that myself. Indeed, it might be amusing to make a 'winstall' command that does bdist_wininst and then runs the executable! >This is *not* a plea for uninstall capability in distutils :-) I think some other folks actually *are* working on that, however. From slash at dotnetslash.net Wed Mar 10 21:04:59 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Wed Mar 10 21:05:04 2004 Subject: [Distutils] Unravelling installation schemes In-Reply-To: <5.1.0.14.0.20040310111130.02141270@mail.telecommunity.com> References: <5.1.0.14.0.20040309180722.03024ec0@mail.telecommunity.com> <5.1.0.14.0.20040309180722.03024ec0@mail.telecommunity.com> <5.1.0.14.0.20040310111130.02141270@mail.telecommunity.com> Message-ID: <20040311020459.GA21466@dotnetslash.net> On Wed, Mar 10, 2004 at 11:29:58AM -0500, Phillip J. Eby wrote: > >If Distutils can make binary packages for most package managers, and it > >can be extended to include "Provides" and "Requires" in the meta-data, > >then any OS's native package manager should have all the information it > >needs to do the right thing at install time. > > Well, it sounds like you have more experience with those package managers > than I do, so it would be helpful if you could lay out a plan for this with > sufficient detail to at least allow me to contemplate implementing it. Somewhere I built a table mapping PEP 241 metadata to RPM, SD-UX (HP's manager), and pkgtool (Solaris). I could probably add dpkg now that I've got some experience there. (My HP is slowly rusting, but I still have code I can read.) > >Why does everyone seem to think that the prefered method of Distutils > >package installations is "setup.py install"? > > Er, perhaps because they prefer it? :) I know I do. It's fine if you're only concerned about a machine or 2. If you've got several, having software managed by the native package manager is the ony thing that will keep you sane. > > What's the point of > >providing bdist_* commands if we're going to perpetualy re-inforce the > >"setup.py install" mindset? I'm not trying to be confrontational here, > >but do we seriously expect everyone who wants to install Distutils > >packages to have a compiler suite in case a package has C extensions? > > That's why I want the dependency system to support installing binary > packages as dependencies, at least on Windows. OK. I got distracted by your discussion of install commands and didn't see anything regarding binary packages. > >Even without C extensions, I suspect you can rule out most Windows users > >by just telling them to "setup.py install". You'll be lucky if you can > >get them to listen long enough when they ask you to explain how to pass > >"install" as an option when they click the setup.py icon. > > Uh, wouldn't you be supplying your application to those people as a py2exe > or other installable with all its dependencies self-contained? Actually, Windows is my weakest platform (sorry, no apologies either ;) I don't know how py2exe works, but I'd prefer a method where dependencies where resolved externally so every package that might require package X doesn't have to include package X. A Windows installer that could download and install dependencies would be nice. > >I really, really, think Distutils should _produce_binary_packages. For > >as many platforms and package managers as possible, with as much > >meta-data as each package manager supports. > > Fantastic, so we can count on your support for specifying what metadata is > needed in a way that will work with all these package managers? :) Absolutely! As I said, I had a decent start of an abstract packager used by implementations of bdist_pkgtool and bdist_sdux. I use them in-house, but my employer has not granted me permission to provide the Python Software Contributor agreement required for them to be included. If _anyone_ is interested. contact be off-line and I'll provide a detailed descriptiong that would allow a clean-room re-write. > Keep in mind that many developers don't have a clue about these package > managers, perhaps not even the one for the system they use! If distutils > requires the developer to understand every packaging system in order to > release a package, it's useless. This much is certain. Packaging is almost a distinct art from coding. Based on what I've done, and what I see that Marc has done with the Egenix packages, I think almost everything that's needed is in place. The only thing possibly missing is "requires" and "provides", and it's been so long since I reviewed a PEP, they may be there for all I know. > However, if all the information needed for packaging can be described in > setup.cfg, I imagine most developers would accept patches from people with > packaging tool experience to add metadata for the various package > managers. I think it's easier than that. There should be almost no difference in the actual metadata required by the different package managers out there. They just use different names for the fields. > Even then, I'm not sure how workable it is, given that dependencies > would now need to include many more URLs for where to get all the > differently-packaged versions of the packages. Couldn't that be handled simply by each bdist_tool knowing how the package-name maps to the binary package name. Different package manager's all have different naming conventions, even if it's only a different extension. 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 vse at srasys.co.in Thu Mar 11 05:58:59 2004 From: vse at srasys.co.in (V.Selvam) Date: Thu Mar 11 05:54:37 2004 Subject: [Distutils] getting value from setup.cfg References: Message-ID: <052b01c40757$db162fb0$0fa8a8c0@selvam> Hi all, Im writting a python module distribution for a small applicatoin. I want to take some value( eg., prefix) from the setup.cfg file and use it in my distribution script. How can i get this from python script ?? Can any one help me in this ?? Thanks in advance Rgds V.Selvam From lars at ibp.de Sat Mar 13 19:00:48 2004 From: lars at ibp.de (Lars Immisch) Date: Sat Mar 13 19:01:51 2004 Subject: [Distutils] SWIG support (or lack thereof) Message-ID: <4053A0B0.5050200@ibp.de> Dear all, I have a few SWIG generated python modules, and I like distutils. distutils only sort-of supports swig. It passes very limited arguments to swig. Most importantly missing for me were macro definitions and include paths. I have attached a minimally intrusive patch that: - reuses include_dirs, define_macros and undef_macros from the C target - adds 'extra_swig_args' (which I need for at least -shadow) The patch was generated from the Python 2.3.2 and should be applied in the distutils directory. The patch solves my immediate problem, but it might be even better to add 'swig_include_dirs', 'swig_define_macros' and 'swig_undef_macros' to the Extension arguments. I volunteer for another patch if there are chances it will be accepted. - Lars -------------- next part -------------- --- core.orig Fri Mar 12 23:55:27 2004 +++ core.py Fri Mar 12 23:56:21 2004 @@ -54,7 +54,8 @@ 'define_macros', 'undef_macros', 'library_dirs', 'libraries', 'runtime_library_dirs', 'extra_objects', 'extra_compile_args', 'extra_link_args', - 'export_symbols', 'depends', 'language') + 'extra_swig_args', 'export_symbols', 'depends', + 'language') def setup (**attrs): """The gateway to the Distutils: do everything your setup script needs --- extension.orig Fri Mar 12 23:55:18 2004 +++ extension.py Fri Mar 12 23:57:41 2004 @@ -94,6 +94,7 @@ extra_objects=None, extra_compile_args=None, extra_link_args=None, + extra_swig_args=None, export_symbols=None, depends=None, language=None, @@ -115,6 +116,7 @@ self.extra_objects = extra_objects or [] self.extra_compile_args = extra_compile_args or [] self.extra_link_args = extra_link_args or [] + self.extra_swig_args = extra_swig_args or [] self.export_symbols = export_symbols or [] self.depends = depends or [] self.language = language --- command/build_ext.orig Fri Mar 12 20:16:24 2004 +++ command/build_ext.py Sat Mar 13 23:52:22 2004 @@ -16,6 +16,7 @@ from distutils.dep_util import newer_group from distutils.extension import Extension from distutils import log +from distutils.ccompiler import gen_preprocess_options # An extension name is just a dot-separated list of Python NAMEs (ie. # the same as a fully-qualified module name). @@ -81,6 +82,8 @@ "specify the compiler type"), ('swig-cpp', None, "make SWIG create C++ files (default is C)"), + ('extra-swig-args', None, + "extra swig options (for example -shadow)"), ] boolean_options = ['inplace', 'debug', 'force', 'swig-cpp'] @@ -108,6 +111,7 @@ self.force = None self.compiler = None self.swig_cpp = None + self.extra_swig_args = None def finalize_options (self): @@ -322,7 +326,8 @@ 'libraries', 'extra_objects', 'extra_compile_args', - 'extra_link_args'): + 'extra_link_args', + 'extra_swig_args'): val = build_info.get(key) if val is not None: setattr(ext, key, val) @@ -429,7 +434,7 @@ # First, scan the sources for SWIG definition files (.i), run # SWIG on 'em to create .c files, and modify the sources list # accordingly. - sources = self.swig_sources(sources) + sources = self.swig_sources(sources, ext) # Next, compile the source code to object files. @@ -492,7 +497,7 @@ target_lang=language) - def swig_sources (self, sources): + def swig_sources (self, sources, extension): """Walk the list of source files in 'sources', looking for SWIG interface (.i) files. Run SWIG on all that are found, and @@ -530,6 +535,16 @@ swig_cmd = [swig, "-python"] if self.swig_cpp: swig_cmd.append("-c++") + + for esa in extension.extra_swig_args: + swig_cmd.append(esa) + + opt = gen_preprocess_options(extension.define_macros + + extension.undef_macros, + extension.include_dirs) + + for o in opt: + swig_cmd.append(o) for source in swig_sources: target = swig_targets[source] From sckm at t-online.de Mon Mar 15 22:16:04 2004 From: sckm at t-online.de (Support commonality) Date: Mon Mar 15 22:16:06 2004 Subject: [Distutils] ::::::::!!!!!! ABSOLUTELY NEW !!!!!!:::::::: laurie Message-ID: ::::::::!!!!!! ABSOLUTELY NEW !!!!!!:::::::: ::::::::::: FRESH T.E.E.N.S. MODELS ::::::::::: NeVeR s_h_o_t before, NeVeR f_u_c_k_e_d so w.i.l.d.l.y before, NeVeR C.uM-SMeAReD ---SO--- HEAvi1Y BEeFoRE. TH.E.SE baBES ! ! ! are s.-i.-m.-.p.-l.-y WAY too k_i_n_k_y AND REALLY have a. s.t.unning ***S*E*X*UAL*** ima.g-ination. >From s.o.l.o P=O=S=I=N=G and d*i*l*d*o GA_M_ES to a.we.so.me !!! MULTI *_0_R_G_1_E_S_* and G=A=N=G=B=A=N=G=S. http://mmm-sex.biz/90mt/?OIb5l !!! A.N.A.L., O.R.A.L. , DOUBLE AND TRIPLE V_A_G_I_N_A F_U_C_K - EvErYThInG that ___you’ve___ b.ee.n L00KING FOR IS HERE !!!!!! TH.E.SE h0t --T-E-E-N-I-E-S-- are R.EA.DY. F0R EvErYThInG JUST T0 ___pLeAsE___ YOU !!!!!! FRESH T.E.E.N B*0*D*Y IS ALL YOU N_E_E_D T0 J.E.r.K =OFF= M O S T @@ p.l.e.a.s.a.n.t.l.y @@ !!! LES-BI-AN S_H_O_W_S, L.IVE. ==S=T=R=I=P== S_H_O_W_S AND MO--RE !!!! S.-I.-G.-N U.-P.- !!!! http://mmm-sex.biz/90mt/?0xaw6 moses auntie gerry collaborate ciceronian aspect platitude clamorous senor polysaccharide bauxite atkins olive property canaveral astonish aperiodic somebody revelation dauphin newtonian weal delia christenson acquiescent eater mayfair carcass chartroom . colloquy awoke melville despite coralberry passivate except greenbelt adjourn ppm lombardy tapir relieve diocesan dandelion urinary astrophysical ammunition breakdown . chuckle drexel quartile quackery incarcerate durward giacomo deceitful conklin doff spicy gaunt allele antiphonal bile augite bleary buckskin charybdis destructor oscillatory arachnid encyclopedic kava blurry populous handymen acrylate paramount . sightseer awry israel sentient ordain projector toolkit inception hurt acclamation commendation flop laurie genii pregnant indent these catenate sexy ash stout concessionaire camp guesswork can't cardiovascular earsplitting bloodstream quaff indicter necropsy dawson . From Customer.Relations at SeekfordSolutions.com Mon Mar 15 23:28:10 2004 From: Customer.Relations at SeekfordSolutions.com (Seekford Solutions, Inc.) Date: Tue Mar 16 02:44:02 2004 Subject: [Distutils] Developer Information from Seekford Solutions, Inc. Message-ID: Greeting from Seekford Solutions, Inc., I am sure you have to get your software development projects done on time and under budget. Don't we all? If you don?t use third-party components, it can be next to impossible. No one wants to reinvent the wheel, especially at a significantly higher cost and sacrificing your precious time. I personally like to spend time with my family and friends; developers need to have lives too. Seekford Solutions, Inc. is a third party component developer that allows you easily integrate Internet communication functionality into your new and existing applications. With very few lines of code you can send and receive emails, upload and download files via HTTP and FTP, synchronize with atomic clocks for highly accurate time stamping and clock setting, communicate with news group servers, and even secure data with highly complex (easy to use though) algorithms for data hashing. Lets not take up too much more of your time. Please check out our selection of .NET and ActiveX technologies at our website: http://www.SeekfordSolutions.com Clients around the world using a large variety of programming languages currently use our controls, many Fortune 500 companies included. Our components are available from a number of major distributors and all products come with free e-mail technical support. Thank you, Customer relations Seekford Solutions, Inc. http://www.SeekfordSolutions.com Tampa, FL If you do not want to receive communications from us, please just reply with REMOVE in the subject. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040315/3954d24d/attachment.html From xslt-admin at gnome.org Tue Mar 16 08:30:23 2004 From: xslt-admin at gnome.org (xslt-admin@gnome.org) Date: Tue Mar 16 08:30:27 2004 Subject: [Distutils] Your message to xslt awaits moderator approval Message-ID: <20040316133023.4294.91487.Mailman@moniker.gnome.org> Your mail to 'xslt' with the subject Re: Re: Re: Your document 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 fdrake at acm.org Wed Mar 17 17:22:17 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Mar 17 17:22:35 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints Message-ID: <200403171722.17585.fdrake@acm.org> I've not heard anything about either of the proposed Distutils sprints for next week. Just as a reminder, these are: - general distutils improvements and wart smashing (http://www.python.org/cgi-bin/moinmoin/DistUtils20) This is generally about avoiding some of the current warts rather than dealing with major new functionality, with the exception of the PEP 262 (http://www.python.org/peps/pep-0262.html) installation database. It's hard to get a good sense of what people's priorities are from the wiki page, but it would certainly be good to knock out some of the more long-standing warts. - dependency support (http://www.python.org/cgi-bin/moinmoin/DistutilsDependencies) This is Phillip Eby's proposal for adding dependency support to distutils, including automatic download and installation of required packages. I don't know what other people's reaction is to his proposal; aspects of it are certainly interesting and mesh well with the PEP 262 installation database. I'd really like to see some improvements happening in either of these areas. I don't know what it takes to get these sprints to go from proposed to concrete, or if we can just take space by squatting (unlikely to be well received ;). Who else will be at the sprints and willing to spend a day or two on distutils? In case there aren't enough outstanding distutils tasks, I'll be glad to propose a few more that I'm going to need to deal with anyway. ;-) -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From pje at telecommunity.com Wed Mar 17 17:57:39 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 17 17:58:23 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <200403171722.17585.fdrake@acm.org> Message-ID: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> At 05:22 PM 3/17/04 -0500, Fred L. Drake, Jr. wrote: >- dependency support > (http://www.python.org/cgi-bin/moinmoin/DistutilsDependencies) > > This is Phillip Eby's proposal for adding dependency support to > distutils, including automatic download and installation of required > packages. FYI, the current implementation at http://cvs.eby-sarna.com/setuptools/ now includes a 'Require' class for specifying dependencies, and a 'find_packages()' function to automatically locate packages in a given directory (so you don't have to list them individually), e.g.: setup( name="setuptools", version="0.01", description="Distutils enhancements", author="Phillip J. Eby", author_email="peak@eby-sarna.com", license="PSF or ZPL", test_suite = 'setuptools.tests.test_suite', requires = [Require('Distutils','1.0.3','distutils')], packages = find_packages(), ) The 'Require' class takes a package name, version, and a module to check. It does not import the module (unless it's written in C), but rather uses a variety of sneaky tricks to do a version check. By default, the attribute looked for is '__version__' and the version class used for comparisons is distutils' StrictVersion. But you can override these defaults with keyword arguments. 'Require' objects can search a specified set of paths, so you can ensure that the target installation location is checked as well as the current sys.path. To handle packages without an explicit version attribute, you can set the requested version to 'None', and specify an attribute (i.e. class, function, or other global) name that must be defined by the module. There's a pretty extensive test suite that verifies all of these capabilities. The implementation also includes a skeleton 'depends' command that's automatically run prior to 'install' if there are any Require's passed to setup(). Right now that command just prints a message to say that it's being run, but sometime before the weekend I'd like to upgrade it to halt the installation with a list of unresolved dependencies, if applicable. I'll also add a 'homepage' keyword to 'Require', so that it can tell you where to go to manually find/download/install them. The current version also provides transparent support for building Pyrex extensions; if you have '.pyx' source files in an extension, the '.c' version will automatically be used instead if Pyrex is not available. Thus, you can easily distribute preprocessed '.c' versions for folks without Pyrex. These features are in addition to those described in my previous post at: http://mail.python.org/pipermail/distutils-sig/2004-March/003758.html Fred, do you think we should go ahead and move setuptools to cvs.zope.org? Actually, I guess first I should ask if you found its "features" mechanism useful for the sub-package dependency management you were prototyping for Zope X3. :) From fdrake at acm.org Wed Mar 17 17:58:09 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Mar 17 17:58:26 2004 Subject: [Distutils] Distutils BOF at PyCon 2004 Message-ID: <200403171758.09627.fdrake@acm.org> I've added a distutils birds-of-a-feather sesion to the BoF schedule at: http://www.python.org/cgi-bin/moinmoin/PyConBofs I'll try to get a set of proposed topics written up this evening. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake at acm.org Wed Mar 17 18:06:51 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Mar 17 18:08:14 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> References: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> Message-ID: <200403171806.51523.fdrake@acm.org> On Wednesday 17 March 2004 05:57 pm, Phillip J. Eby wrote: > Fred, do you think we should go ahead and move setuptools to > cvs.zope.org? Yes, we can resolve this now. (This was the next email I needed to write today anyway. ;) Please check this in to cvs.zope.org as Packages/setuptools/. My preferred arrangement is to create a directory of that name, and add the package and any README.txt, setup.py, and such at that layer (see Packages/zpkgtools/ for an example of what I mean). -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From pje at telecommunity.com Wed Mar 17 18:21:56 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 17 18:22:35 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <200403171806.51523.fdrake@acm.org> References: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> Message-ID: <5.1.1.6.0.20040317181552.02d06780@telecommunity.com> At 06:06 PM 3/17/04 -0500, Fred L. Drake, Jr. wrote: >On Wednesday 17 March 2004 05:57 pm, Phillip J. Eby wrote: > > Fred, do you think we should go ahead and move setuptools to > > cvs.zope.org? > >Yes, we can resolve this now. (This was the next email I needed to write >today anyway. ;) Please check this in to cvs.zope.org as >Packages/setuptools/. My preferred arrangement is to create a directory of >that name, and add the package and any README.txt, setup.py, and such at that >layer (see Packages/zpkgtools/ for an example of what I mean). Just to clarify, this would be equivalent to taking what's here: http://cvs.eby-sarna.com/setuptools/ and putting it here: http://cvs.zope.org/Packages/setuptools/ yes? From amk at amk.ca Wed Mar 17 19:16:36 2004 From: amk at amk.ca (A.M. Kuchling) Date: Wed Mar 17 19:16:42 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> References: <200403171722.17585.fdrake@acm.org> <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> Message-ID: <20040318001636.GA1982@rogue.amk.ca> On Wed, Mar 17, 2004 at 05:57:39PM -0500, Phillip J. Eby wrote: > Fred, do you think we should go ahead and move setuptools to > cvs.zope.org? Actually, I guess first I should ask if you found its Shouldn't it go in the Python CVS tree, probably in nondist/sandbox? --amk From pje at telecommunity.com Wed Mar 17 19:27:31 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 17 19:28:11 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <20040318001636.GA1982@rogue.amk.ca> References: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> <200403171722.17585.fdrake@acm.org> <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> Message-ID: <5.1.1.6.0.20040317191920.02693470@telecommunity.com> At 07:16 PM 3/17/04 -0500, A.M. Kuchling wrote: >On Wed, Mar 17, 2004 at 05:57:39PM -0500, Phillip J. Eby wrote: > > Fred, do you think we should go ahead and move setuptools to > > cvs.zope.org? Actually, I guess first I should ask if you found its > >Shouldn't it go in the Python CVS tree, probably in nondist/sandbox? > >--amk Maybe so, but as a practical matter, I don't have commit access to the Python CVS. :) Also, isn't it customary for packages targeted for non-current versions of Python to live outside the Python CVS? E.g. logging, Optik, et al? Even if setuptools were adopted for 2.4, it would still need to be separately obtainable for 2.2 and 2.3 users. From tim.one at comcast.net Wed Mar 17 21:14:23 2004 From: tim.one at comcast.net (Tim Peters) Date: Wed Mar 17 21:14:15 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <5.1.1.6.0.20040317191920.02693470@telecommunity.com> Message-ID: [Phillip J. Eby] >>> Fred, do you think we should go ahead and move setuptools to >>> cvs.zope.org? [A.M. Kuchling] >> Shouldn't it go in the Python CVS tree, probably in nondist/sandbox? [Phillip] > Maybe so, but as a practical matter, I don't have commit access to the > Python CVS. :) And with an attitude like that, you're never gonna get it . > Also, isn't it customary for packages targeted for non-current > versions of Python to live outside the Python CVS? E.g. logging, > Optik, et al? There's no non-accidental relation, as the nondist/ subtree has no relationship to Python releases. > Even if setuptools were adopted for 2.4, it would still need to > be separately obtainable for 2.2 and 2.3 users. The practical question is who y'all expect to *work* on this project. That you (Phillip) don't have commit access to the Python tree is an important point. If someone else who intends to work on it doesn't have commit access to Zope CVS, and doesn't want to sign the contributor thingie Zope Corp usually requires to get such access, then that's also an important point. Despite that Zope Corp funded initial work on the SpamBayes project, it started its life in the Python sandbox ("because" it was always going to be released under a PSF license), and we decided it was easiest for our contributors to set up a new SourceForge project for it. Aim to make life easiest for your likely primary contributors. From pje at telecommunity.com Wed Mar 17 21:42:37 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 17 21:37:04 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: References: <5.1.1.6.0.20040317191920.02693470@telecommunity.com> Message-ID: <5.1.0.14.0.20040317213532.02dee290@mail.telecommunity.com> You know, it's really amazing how many more messages have been posted here on the subject of what CVS repository 'setuptools' should live in, than have commented on the design or implementation of setuptools itself. :) At 09:14 PM 3/17/04 -0500, Tim Peters wrote: >[Phillip J. Eby] > >>> Fred, do you think we should go ahead and move setuptools to > >>> cvs.zope.org? > >[A.M. Kuchling] > >> Shouldn't it go in the Python CVS tree, probably in nondist/sandbox? > >[Phillip] > > Maybe so, but as a practical matter, I don't have commit access to the > > Python CVS. :) > >And with an attitude like that, you're never gonna get it . Um, you mean my "practicality beats purity" attitude? :) > > Also, isn't it customary for packages targeted for non-current > > versions of Python to live outside the Python CVS? E.g. logging, > > Optik, et al? > >There's no non-accidental relation, as the nondist/ subtree has no >relationship to Python releases. Ah. > > Even if setuptools were adopted for 2.4, it would still need to > > be separately obtainable for 2.2 and 2.3 users. > >The practical question is who y'all expect to *work* on this project. That >you (Phillip) don't have commit access to the Python tree is an important >point. If someone else who intends to work on it doesn't have commit access >to Zope CVS, and doesn't want to sign the contributor thingie Zope Corp >usually requires to get such access, then that's also an important point. Doesn't Python CVS access require a similar "contributor thingie", for the same reasons as Zope? >Despite that Zope Corp funded initial work on the SpamBayes project, it >started its life in the Python sandbox ("because" it was always going to be >released under a PSF license), and we decided it was easiest for our >contributors to set up a new SourceForge project for it. > >Aim to make life easiest for your likely primary contributors. Fred and I are both zope.org CVS committers, and for the sprint I sort of assumed Fred and/or Jim would have "contributor thingies" on hand for people to sign if needed. :) From tim.one at comcast.net Wed Mar 17 22:14:27 2004 From: tim.one at comcast.net (Tim Peters) Date: Wed Mar 17 22:14:20 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <5.1.0.14.0.20040317213532.02dee290@mail.telecommunity.com> Message-ID: [Phillip J. Eby] > You know, it's really amazing how many more messages have been posted > here on the subject of what CVS repository 'setuptools' should live > in, than have commented on the design or implementation of setuptools > itself. :) But I understand CVS <0.9 wink>. > ... > Doesn't Python CVS access require a similar "contributor thingie", In theory, but nobody has signed one yet (there's no form to sign yet, just a proposed form that doesn't actually make sense for various reasons -- which is why it hasn't moved beyond "proposed" status). > for the same reasons as Zope? That's a different question, and as a Zope employee I'm not allowed to speculate about Zope Corp policies . The PSF wants a form for reasons that escape me now -- probably to ensure that there's no actionable question about the PSF's right to slap its own license on contributions, plus paying homage to various cover-your-ass legalistic superstitions "because everyone else does". > ... > Fred and I are both zope.org CVS committers, and for the sprint I > sort of assumed Fred and/or Jim would have "contributor thingies" on > hand for people to sign if needed. :) You should really find out in advance whether contributors are willing to sign those. For example, if I weren't already a Zope employee, I wouldn't sign it on the spot-- it's too complicated for me to sign without paying a lawyer to review it first (I don't even know what half of it really means). BTW, if this code is intended to be released under a PSF license eventually, it probably won't help to have people sign something putting it under the ZPL first. Vice versa if it's intended to be released under the ZPL. SpamBayes moved to SourceForge partly because they didn't ask us to sign pages of licensing agreements just to use a CVS repository. From fdrake at acm.org Wed Mar 17 22:50:02 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Mar 17 22:50:18 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <5.1.1.6.0.20040317181552.02d06780@telecommunity.com> References: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> <5.1.1.6.0.20040317181552.02d06780@telecommunity.com> Message-ID: <200403172250.02418.fdrake@acm.org> On Wednesday 17 March 2004 06:21 pm, Phillip J. Eby wrote: > Just to clarify, this would be equivalent to taking what's here: > > http://cvs.eby-sarna.com/setuptools/ > > and putting it here: > > http://cvs.zope.org/Packages/setuptools/ Yep! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From fdrake at acm.org Wed Mar 17 23:10:52 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Mar 17 23:11:08 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <5.1.1.6.0.20040317191920.02693470@telecommunity.com> References: <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> <5.1.1.6.0.20040317191920.02693470@telecommunity.com> Message-ID: <200403172310.52787.fdrake@acm.org> On Wed, Mar 17, 2004 at 05:57:39PM -0500, Phillip J. Eby wrote: > Fred, do you think we should go ahead and move setuptools to > cvs.zope.org? Actually, I guess first I should ask if you found its At 07:16 PM 3/17/04 -0500, A.M. Kuchling wrote: >Shouldn't it go in the Python CVS tree, probably in nondist/sandbox? This would also be fine by me. Whether the code is in the zope.org or python.sf.net repositories is immaterial to Zope's immediate needs (I'm fairly certain of this); whether it's covered by the PSF license or the ZPL2 is also irrelevant. (If Phillip commits it to the zope.org repository, all such versions will be available by the ZPL2. I think the python.sf.net repository is more flexible, but that's not important.) On Wednesday 17 March 2004 07:27 pm, Phillip J. Eby wrote: > Maybe so, but as a practical matter, I don't have commit access to the > Python CVS. :) As Tim suggests, this is something that can be dealt with. > Also, isn't it customary for packages targeted for non-current versions of > Python to live outside the Python CVS? E.g. logging, Optik, et al? Even > if setuptools were adopted for 2.4, it would still need to be separately > obtainable for 2.2 and 2.3 users. Your examples were developed for current versions of Python when they were initially developed; they've remained available for older versions as well. Distutils itself is in Python's CVS and is maintained for older versions at all (there's a top-level module you can check out and get a separate distutils distribution). So I'd say that *if* setuptools is being developed as a potential addition to Python's standard library, it's quite reasonable for it to be in Python's CVS. My own thinking is that its more of a testbed for enhancements to distutils. It may be that its also useful as an add-on package that works with older versions of distutils as well (in which case, the Python CVS is still a good place to maintain it). As it stands, the code is Phillip's, and he can do with it as he pleases. I won't object to using the zope.org CVS, though the python.sf.net CVS may prove better in the long term, especially if setuptools should maintain an identity of it's own. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From pje at telecommunity.com Wed Mar 17 23:30:06 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Wed Mar 17 23:24:34 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <200403172310.52787.fdrake@acm.org> References: <5.1.1.6.0.20040317191920.02693470@telecommunity.com> <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> <5.1.1.6.0.20040317191920.02693470@telecommunity.com> Message-ID: <5.1.0.14.0.20040317232206.036b4960@mail.telecommunity.com> At 11:10 PM 3/17/04 -0500, Fred L. Drake, Jr. wrote: >At 07:16 PM 3/17/04 -0500, A.M. Kuchling wrote: > >Shouldn't it go in the Python CVS tree, probably in nondist/sandbox? > >This would also be fine by me. Whether the code is in the zope.org or >python.sf.net repositories is immaterial to Zope's immediate needs (I'm >fairly certain of this); whether it's covered by the PSF license or the ZPL2 >is also irrelevant. (If Phillip commits it to the zope.org repository, all >such versions will be available by the ZPL2. I think the python.sf.net >repository is more flexible, but that's not important.) > >On Wednesday 17 March 2004 07:27 pm, Phillip J. Eby wrote: > > Maybe so, but as a practical matter, I don't have commit access to the > > Python CVS. :) > >As Tim suggests, this is something that can be dealt with. Okay, then I'm somewhat more inclined to lean towards the Python CVS, although naturally the most convenient thing for my packages is to leave it in the Eby-Sarna CVS. >Your examples were developed for current versions of Python when they were >initially developed; they've remained available for older versions as well. >Distutils itself is in Python's CVS and is maintained for older versions at >all (there's a top-level module you can check out and get a separate >distutils distribution). So I'd say that *if* setuptools is being developed >as a potential addition to Python's standard library, it's quite reasonable >for it to be in Python's CVS. My own thinking is that its more of a testbed >for enhancements to distutils. It may be that its also useful as an add-on >package that works with older versions of distutils as well (in which case, >the Python CVS is still a good place to maintain it). Yes, it's intended to be both a testbed for future distutils enhancements, and an immediately usable "field upgrade" for developers that want to use its features. >As it stands, the code is Phillip's, and he can do with it as he pleases. I >won't object to using the zope.org CVS, though the python.sf.net CVS may >prove better in the long term, especially if setuptools should maintain an >identity of it's own. Okay, so I guess the Python CVS would be fine, although I have never used SourceForge's CVS facilities as a developer before, so it may take me a while to get my setup figured out. If all else fails, you guys can always send me the sprint results in the form of a patch against the Eby-Sarna CVS. :) From slash at dotnetslash.net Wed Mar 17 23:35:17 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Wed Mar 17 23:35:23 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: References: <5.1.0.14.0.20040317213532.02dee290@mail.telecommunity.com> Message-ID: <20040318043517.GA11418@dotnetslash.net> On Wed, Mar 17, 2004 at 10:14:27PM -0500, Tim Peters wrote: > > ... > > Doesn't Python CVS access require a similar "contributor thingie", > > In theory, but nobody has signed one yet (there's no form to sign yet, just > a proposed form that doesn't actually make sense for various reasons -- > which is why it hasn't moved beyond "proposed" status). Really..... I was asked to sign one and agree to be maintainer in order to get commit access for the Solaris and HP-UX bdist tools. Because they asked for "Employer" and because by employer is open source clueless, the PSF board (and I) agreed to pull the code. > > for the same reasons as Zope? > > That's a different question, and as a Zope employee I'm not allowed to > speculate about Zope Corp policies . The PSF wants a form for reasons > that escape me now -- probably to ensure that there's no actionable question > about the PSF's right to slap its own license on contributions, plus paying > homage to various cover-your-ass legalistic superstitions "because everyone > else does". Think "SCO". If Linus had contributor agreements from those SCO/Caldera employees Groklaw readers wouldn't have to be bit-dumpster diving to find emails that show their employer approved their participation. It's a fair thing to ask for reasonably significant contributions, I think. > > ... > > Fred and I are both zope.org CVS committers, and for the sprint I > > sort of assumed Fred and/or Jim would have "contributor thingies" on > > hand for people to sign if needed. :) > > You should really find out in advance whether contributors are willing to > sign those. For example, if I weren't already a Zope employee, I wouldn't > sign it on the spot-- it's too complicated for me to sign without paying a > lawyer to review it first (I don't even know what half of it really means). The Zope one or the PSF one? The PSF one is basically "we agree that we both have copyright and can do whatever we want with the code." (Actually, I think there's 3 different options so you can choose what suits your needs best.) > BTW, if this code is intended to be released under a PSF license eventually, > it probably won't help to have people sign something putting it under the > ZPL first. Vice versa if it's intended to be released under the ZPL. > SpamBayes moved to SourceForge partly because they didn't ask us to sign > pages of licensing agreements just to use a CVS repository. As much as I hate to say this, it's only going to get worse. A year ago, I never would have dreamed of asking for a copyright agreement if someone wanted to contribute to one of my projects (that I can't publish because my employer owns my every thought). Today, I probably would, if only to have a physical (non-digital) audit trail of contributors. At this point, it's like digging foxholes. We have to fortify our defenses in preparation for more "IP" (should be "intellectual rights" -- it is NOT _property!) attacks. I haven't read the ZPL in a while and I have no idea what they have to sign, however, if it's similar to the PSF agreement then once the maintainer has "joint copyright", they can shift the excercise of their rights from the PSF license to the ZPL to the GPL and back again as needed. None of the transitions would change pre-existing licenses, and at some transitions you could probably expect a fork since the other "joint copyright holders" retain full and equal rights as well. I don't mean to put a damper on things. It's just another challenge that open source community has to overcome. IANALBILWIHT 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 tim.one at comcast.net Thu Mar 18 01:21:49 2004 From: tim.one at comcast.net (Tim Peters) Date: Thu Mar 18 01:21:41 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <20040318043517.GA11418@dotnetslash.net> Message-ID: [Tim, on PSF contributor agreements] >> In theory, but nobody has signed one yet (there's no form to sign >> yet, just a proposed form that doesn't actually make sense for >> various reasons -- which is why it hasn't moved beyond "proposed" >> status). [Mark W. Alexander] > Really..... I was asked to sign one In http://www.python.org/sf/531901 Marc-Andre said The PSF will still require you to sign a contributor agreement for these addition, though, after these have been through the legal review phase. You didn't sign, and the forms still aren't through legal review. > and agree to be maintainer That's a different issue -- that was a PEP 2 requirement. > in order to get commit access for the Solaris and HP-UX bdist tools. Some form was needed just so that Marc-Andre could check in your stuff on your behalf. The issue was that the IP rights in your patch appeared to belong to your employer, and it was a substantial piece of work so it wasn't reasonable to overlook that. It doesn't really matter for short patches (an employer could try to sue over one of those, but wouldn't prevail). Most contributions to Python aren't entangled at all. > Because they asked for "Employer" and because by employer is open > source clueless, the PSF board (and I) agreed to pull the code. I'm on the PSF board, so I even know who your employer was . > ... > Think "SCO". If Linus had contributor agreements from those > SCO/Caldera employees Groklaw readers wouldn't have to be > bit-dumpster diving to find emails that show their employer approved > their participation. This isn't the place for an SCO debate, but no amount of paper can prevent a lawsuit. It can discourage one, but the PSF has other things in its favor discouraging lawsuits (see below). > It's a fair thing to ask for reasonably significant contributions, I > think. Yes, and the PSF is still trying to get a reasonable contributor form in place. The one copied from Zope Corp doesn't make sense for the PSF (as mentioned last time); for example, because Python's CVS is controlled by SourceForge (while Zope's is controlled by Zope), the words saying that the PSF may disable your account are simply absurd (the PSF cannot disable your SourceForge account); the bit about you agreeing that using your account password constitutes acceptance of the agreement is even sillier, because the PSF has no way of knowing whether you use your password (SourceForge might be able to tell -- we can't). An agreement that spouts nonsense stands poor chance of being upheld. > ... > The Zope one or the PSF one? The PSF one is basically "we agree that > we both have copyright and can do whatever we want with the code." > (Actually, I think there's 3 different options so you can choose what > suits your needs best.) The Zope one. The proposed PSF one was essentially copied from Zope's. There are at present no PSF forms available, just proposed forms that haven't passed legal review. Our attorney du jour happens to hate them, so to make progress we'll have to get a different attorney or different forms. ... > I don't mean to put a damper on things. It's just another challenge > that open source community has to overcome. Or ignore <0.5 wink>. There's potentially money in going after Linux. Nobody is going to make a dime going after the PSF, and because the PSF is a public charity (under US tax law), its primary assets can only end up in the hands of government agencies or other public charities. When the March of Dimes starts suing Open Source public charities, or SCO is recognized by the IRS as a government agency, then I'll start to worry about the PSF -- before then, the worst they can do is drive the PSF bankrupt. We want to discourage that too, but can't really prevent it if someone with a few spare million lawyer dollars is determined to make it happen. From mal at egenix.com Thu Mar 18 03:39:16 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Mar 18 03:39:13 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: <5.1.0.14.0.20040317232206.036b4960@mail.telecommunity.com> References: <5.1.1.6.0.20040317191920.02693470@telecommunity.com> <5.1.1.6.0.20040317174013.01e90130@telecommunity.com> <5.1.1.6.0.20040317191920.02693470@telecommunity.com> <5.1.0.14.0.20040317232206.036b4960@mail.telecommunity.com> Message-ID: <40596034.2050509@egenix.com> Phillip J. Eby wrote: > At 11:10 PM 3/17/04 -0500, Fred L. Drake, Jr. wrote: > >> At 07:16 PM 3/17/04 -0500, A.M. Kuchling wrote: >> >Shouldn't it go in the Python CVS tree, probably in nondist/sandbox? >> >> This would also be fine by me. Whether the code is in the zope.org or >> python.sf.net repositories is immaterial to Zope's immediate needs (I'm >> fairly certain of this); whether it's covered by the PSF license or >> the ZPL2 >> is also irrelevant. (If Phillip commits it to the zope.org >> repository, all >> such versions will be available by the ZPL2. I think the python.sf.net >> repository is more flexible, but that's not important.) Note: if you ever want your code to go into the Python distribution you'll hve to make sure that you own the copyright on it and have full rights and title to the code. The Zope contributor agreement as it stands causes rights and title to be shared between Zope Corp and yourself (whatever that means). In the end it's probably better for legal reasons to keep Zope Corp out of this and leave the code in your CVS or in a separate SourcForge project CVS (this is the way that many other contributors of larger chunks of code have done it and it's the most flexible). Your decision, really :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 18 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 28 days left EuroPython 2004, G?teborg, Sweden 80 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From slash at dotnetslash.net Thu Mar 18 12:10:58 2004 From: slash at dotnetslash.net (Mark W. Alexander) Date: Thu Mar 18 12:11:02 2004 Subject: [Distutils] Distutils at the PyCon 2004 sprints In-Reply-To: References: <20040318043517.GA11418@dotnetslash.net> Message-ID: <20040318171058.GA12424@dotnetslash.net> On Thu, Mar 18, 2004 at 01:21:49AM -0500, Tim Peters wrote: > Some form was needed just so that Marc-Andre could check in your stuff on > your behalf. The issue was that the IP rights in your patch appeared to > belong to your employer, and it was a substantial piece of work so it wasn't > reasonable to overlook that. It doesn't really matter for short patches (an > employer could try to sue over one of those, but wouldn't prevail). Most > contributions to Python aren't entangled at all. > > > Because they asked for "Employer" and because by employer is open > > source clueless, the PSF board (and I) agreed to pull the code. > > I'm on the PSF board, so I even know who your employer was . if was==still_is: # will be true until new_offer >= exisiting_recompense I'm sure I have your sympathies ;) FWIW, I have since managed to get Mark Lutz in for on-site training and Python is now the "official" language of our (worldwide!) division (although I still have to thrash some perl-mongers soundly to make them understand that other people have to be able to follow and maintain their code). Progress is being made. It's just soooo daaaaarrrrn sssllooooooowwwww...... > This isn't the place for an SCO debate, but no amount of paper can prevent a > lawsuit. It can discourage one, but the PSF has other things in its favor > discouraging lawsuits (see below). Discouragement is good. > > It's a fair thing to ask for reasonably significant contributions, I > > think. > > Yes, and the PSF is still trying to get a reasonable contributor form in > place. I understand and completely support the PSF's stance. The only suggestion I have would be to place a more prominent notice about "significant contributions" requiring an agreement. I only found out about it after the fact, and was seriously p.o.'ed _at_myself_ for placing the PSF in that position. > > I don't mean to put a damper on things. It's just another challenge > > that open source community has to overcome. > > Or ignore <0.5 wink>. There's potentially money in going after Linux. > Nobody is going to make a dime going after the PSF, and because the PSF is a > public charity (under US tax law), its primary assets can only end up in the > hands of government agencies or other public charities. When the March of > Dimes starts suing Open Source public charities, or SCO is recognized by the > IRS as a government agency, then I'll start to worry about the PSF -- before > then, the worst they can do is drive the PSF bankrupt. We want to > discourage that too, but can't really prevent it if someone with a few spare > million lawyer dollars is determined to make it happen. This is very informative! Large open source projects have a great case for becoming public charities based on the educational aspect alone. (This is how our local LUG is pursuing 501(3c) status). For Big Corporation X to somehow "attack" a public charity would be very bad PR. Pass my best wishes and thanks again on to the board. 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 fdrake at acm.org Fri Mar 19 12:32:15 2004 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Fri Mar 19 12:32:32 2004 Subject: [Distutils] Distutils BOF at PyCon 2004 Message-ID: <200403191232.15614.fdrake@acm.org> I've added a proposed list of topics for a Distutils BOF for PyCon: http://www.python.org/cgi-bin/moinmoin/DistutilsBof If anyone would like to add to the list or expand on it, or add their name to it as planning to attend, that would be great. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From pje at telecommunity.com Fri Mar 19 13:18:07 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Fri Mar 19 13:12:27 2004 Subject: [Distutils] Distutils BOF at PyCon 2004 In-Reply-To: <200403191232.15614.fdrake@acm.org> Message-ID: <5.1.0.14.0.20040319131000.02958140@mail.telecommunity.com> At 12:32 PM 3/19/04 -0500, Fred L. Drake, Jr. wrote: >I've added a proposed list of topics for a Distutils BOF for PyCon: > > http://www.python.org/cgi-bin/moinmoin/DistutilsBof > >If anyone would like to add to the list or expand on it, or add their name to >it as planning to attend, that would be great. FYI, with respect to the "bundling distutils extensions with small distributions" issue raised on the above page, my current plan is to create a "bootstrap" module from which a setup.py can import a function (e.g. 'from use_setuptools import require_version') that will check whether the desired version of setuptools is present on sys.path, and if not, download and extract it into the same directory as the setup.py script. In this way, it would not be necessary to distribute the entire setuptools distribution with a small package, just the one bootstrap file. Meanwhile, if somebody wants to avoid the repeated downloads of setuptools when installing small packages, they could always install it directly. It's not a perfect solution, but it's one that could be used as a stopgap until setuptools-like capabilities are present in the stdlib. From tommie at iae.nl Sun Mar 21 06:53:51 2004 From: tommie at iae.nl (tommie@iae.nl) Date: Sun Mar 21 06:53:55 2004 Subject: [Distutils] Re: ***SPAM?*** Re: Hello In-Reply-To: <20040321115337.0EE3DAA0A@mailhub3.vianetworks.nl> References: <20040321115337.0EE3DAA0A@mailhub3.vianetworks.nl> Message-ID: <20040321115351.74544AA00@mailhub3.vianetworks.nl> This account will cease to exist on: Dit account wordt opgeheven op: 1 sep 2003 Thomas. From jfern at cng.fr Tue Mar 23 03:22:12 2004 From: jfern at cng.fr (jfern@cng.fr) Date: Tue Mar 23 03:22:23 2004 Subject: [Distutils] Help (python module) Message-ID: <1080030132.405ff3b427e60@webmail.cng.fr> Hello, I'm trying to install the biopython module on our lab computer: (biopython-1.24). I do this: > tar -xzvpf biopython-1.24.tgz > cd biopython-1.24 > python setup.py install And..... running install running build running build_py running build_ext building 'Bio.PDB.mmCIF.MMCIFlex' extension gcc -pthread -shared build/temp.linux-i686-2.3/Bio/PDB/mmCIF/lex.yy.o build/temp.linux-i686-2.3/Bio/PDB/mmCIF/MMCIFlexmodule.o -lfl -o build/lib.linux-i686-2.3/Bio/PDB/mmCIF/MMCIFlex.so /usr/bin/ld: cannot find -lfl collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 What can I do? Thanks, FERNANDEZ Julien INSERM E0223 - FRANCE Molecular Neurogenetic Laboratory From amk at amk.ca Tue Mar 23 07:10:00 2004 From: amk at amk.ca (A.M. Kuchling) Date: Tue Mar 23 07:10:17 2004 Subject: [Distutils] Help (python module) In-Reply-To: <1080030132.405ff3b427e60@webmail.cng.fr> References: <1080030132.405ff3b427e60@webmail.cng.fr> Message-ID: <20040323121000.GA13326@rogue.amk.ca> On Tue, Mar 23, 2004 at 09:22:12AM +0100, jfern@cng.fr wrote: > /usr/bin/ld: cannot find -lfl Well, obviously you need to find the fl library. It looks like it might be part of flex, so you could check that you have a package named flex or flex-dev or libflex or something like that installed. --amk From dxay924w at pa.airnet.ne.jp Tue Mar 23 11:25:12 2004 From: dxay924w at pa.airnet.ne.jp (Alexis Sands) Date: Tue Mar 23 12:31:18 2004 Subject: [Distutils] This is a VERY different affiliate program Message-ID: <503-13x-$py-p11@8cho3e> An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040323/f84f77f2/attachment.html From House.IMSMail.System01 at housemail.house.gov Wed Mar 24 11:55:04 2004 From: House.IMSMail.System01 at housemail.house.gov (House IMSMail System01) Date: Wed Mar 24 11:55:20 2004 Subject: [Distutils] Re: Delivery Server Message-ID: <7DF2A4D8586BDA41AC5502DDEF2C914339B3C3@ims01.house.gov> Message contains prohibited attachment; message rejected. Contact the intended recipient for an alternative method to transmit attachment. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040324/6e71b872/attachment.html From postmaster at anoto.com Thu Mar 25 03:51:56 2004 From: postmaster at anoto.com (postmaster@anoto.com) Date: Thu Mar 25 03:52:01 2004 Subject: [Distutils] Content violation Message-ID: <200403250851.i2P8pZuG000750@mail.anoto.com> Content violation found in email message. From: distutils-sig@python.org To: support@cpen.com File(s): message.scr Matching filename: *.scr From bob at redivi.com Thu Mar 25 11:11:34 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 25 11:08:12 2004 Subject: [Distutils] [ANN] pkgdata Message-ID: <15DD4CFC-7E77-11D8-BB21-000A95686CD8@redivi.com> As per the BOF last night, here is the pkgdata module that I mentioned. Currently the only project using it is pygame. The "sys.datapath" mechanism that I talked about *could actually be implemented* on top of this system, supposing an appropriate adapter was written to support it! Remember: pkgdata is *just a hook*. It doesn't do anything other give the eventual option of doing something smarter than os.path.join(os.path.basedir(__file__), data). When you figure out what something smarter is, or you change your mind about what the smarter solution is (inside of an app bundle vs. system wide install, etc.), you don't have to refactor any of the code that uses pkgdata. The current implementation, and documentation, is here: http://undefined.org/python/pkgdata-0.1.tgz """ pkgdata is a simple, extensible way for a package to acquire data file resources. The implementation is lightweight, and is intended to be included *inside* your Python packages. """ It's based on PyProtocols (but the implementation doesn't require it unless you want to override the default mechanism). Basically, it's useful for py2exe and OS X bundlebuilder type situations. It's a simple and flexible alternative to os.path.join(os.path.dirname(__file__), "myresource"). The source is simple, and has lots of examples. Read if you're interested. If you would like to see additional examples of its use, here are the interesting things to look at if you check out pygame CVS: pygame/lib/pkgdata.py (this is the pkgdata "client") pygame/lib/macosx.py (usage from python) pygame/src/font.c (usage from C) pygame/src/display.c (more usage from C) pygame/examples/macosx/aliens_app_example/ (this has the pkgdata "host adapter" for bundlebuilder type situations) The fact that it uses PyProtocols is just personal preference. It could work on top of any sort of global registry, but PyProtocols is a really nice global registry that made my implementation extremely terse. -bob From pje at telecommunity.com Thu Mar 25 11:28:51 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Mar 25 11:23:00 2004 Subject: [Distutils] [ANN] pkgdata In-Reply-To: <15DD4CFC-7E77-11D8-BB21-000A95686CD8@redivi.com> Message-ID: <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> At 11:11 AM 3/25/04 -0500, Bob Ippolito wrote: >As per the BOF last night, here is the pkgdata module that I >mentioned. Currently the only project using it is pygame. The >"sys.datapath" mechanism that I talked about *could actually be >implemented* on top of this system, supposing an appropriate adapter was >written to support it! Remember: pkgdata is *just a hook*. It doesn't >do anything other give the eventual option of doing something smarter than >os.path.join(os.path.basedir(__file__), data). When you figure out what >something smarter is, or you change your mind about what the smarter >solution is (inside of an app bundle vs. system wide install, etc.), you >don't have to refactor any of the code that uses pkgdata. Do you plan to support the PEP 302 'get_data()' facility? From bob at redivi.com Thu Mar 25 13:28:35 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 25 13:25:21 2004 Subject: [Distutils] [ANN] pkgdata In-Reply-To: <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> References: <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> Message-ID: <3A85E6C4-7E8A-11D8-BB21-000A95686CD8@redivi.com> On Mar 25, 2004, at 11:28 AM, Phillip J. Eby wrote: > At 11:11 AM 3/25/04 -0500, Bob Ippolito wrote: >> As per the BOF last night, here is the pkgdata module that I >> mentioned. Currently the only project using it is pygame. The >> "sys.datapath" mechanism that I talked about *could actually be >> implemented* on top of this system, supposing an appropriate adapter >> was written to support it! Remember: pkgdata is *just a hook*. It >> doesn't do anything other give the eventual option of doing something >> smarter than os.path.join(os.path.basedir(__file__), data). When you >> figure out what something smarter is, or you change your mind about >> what the smarter solution is (inside of an app bundle vs. system wide >> install, etc.), you don't have to refactor any of the code that uses >> pkgdata. > > Do you plan to support the PEP 302 'get_data()' facility? Probably not, I don't think anyone ever implemented it, and it seems more complicated than it needs to be. If someone really does use it, and thinks it should be implemented, please speak up. -bob From pje at telecommunity.com Thu Mar 25 14:37:58 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Mar 25 14:32:14 2004 Subject: [Distutils] [ANN] pkgdata In-Reply-To: <3A85E6C4-7E8A-11D8-BB21-000A95686CD8@redivi.com> References: <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> Message-ID: <5.1.0.14.0.20040325143021.01eb2460@mail.telecommunity.com> At 01:28 PM 3/25/04 -0500, Bob Ippolito wrote: >On Mar 25, 2004, at 11:28 AM, Phillip J. Eby wrote: > >>At 11:11 AM 3/25/04 -0500, Bob Ippolito wrote: >>>As per the BOF last night, here is the pkgdata module that I >>>mentioned. Currently the only project using it is pygame. The >>>"sys.datapath" mechanism that I talked about *could actually be >>>implemented* on top of this system, supposing an appropriate adapter was >>>written to support it! Remember: pkgdata is *just a hook*. It doesn't >>>do anything other give the eventual option of doing something smarter >>>than os.path.join(os.path.basedir(__file__), data). When you figure out >>>what something smarter is, or you change your mind about what the >>>smarter solution is (inside of an app bundle vs. system wide install, >>>etc.), you don't have to refactor any of the code that uses pkgdata. >> >>Do you plan to support the PEP 302 'get_data()' facility? > >Probably not, I don't think anyone ever implemented it, and it seems more >complicated than it needs to be. If someone really does use it, and >thinks it should be implemented, please speak up. Perhaps I was unclear. What I meant was closer to, "why not expose this functionality as methods on a __loader__ attribute of the module, and update PEP 302 if needed?" I'd love there to be a standard facility in Python for doing this, and have it be supported for import-from-zip, py2exe, and all the other possible routes to importing a module. As far as I'm aware, PEP 302 is the only PEP that even vaguely touches on this, so it seems to make sense to me to update it. As you probably know, PEAK has 'config.fileNearModule()' to do this, but it doesn't have any mechanisms for dealing with non-file imports. I intend to try to implement the PEP 302 route once I get around to needing it. (Although, in all honesty I'm unlikely to embrace zipfile imports until there's a way to use C extensions in them, at which point it becomes a cool way to do simple binary installs of large packages.) From dschult at mail.colgate.edu Thu Mar 25 14:37:27 2004 From: dschult at mail.colgate.edu (Dan Schult) Date: Thu Mar 25 14:38:30 2004 Subject: [Distutils] build subcommand order Message-ID: <406334F7.nailY4119SB4@harold.colgate.edu> I have been using swig 1.3 along with distutils to make a package and I'm having trouble with the subcommand order for "build". The order is set at the bottom of command.build.py to be: build_py build_clibs build_ext build_scripts My problem is that swig gets run during build_ext and creates a class definition in a new *.py file. That python file needs to be moved into the staging area, but build_py doesn't find it because it is created AFTER build_py is run. I propose a simple change of the order of the build commands so that build_py is last. It is unlikely that build_py would make any actions that affect the other command, but quite likely (especially given the nature of Swig) that other actions may create python files. I know one can always use: python setup.py build_ext build_py but I don't think every person that is packaging (or unpackaging) a swig distribution should have to document that --or figure it out. If there is a better place to submit changes/improvements please le me know. Thanks for a Great Package!! Dan Schult From theller at python.net Thu Mar 25 14:49:26 2004 From: theller at python.net (Thomas Heller) Date: Thu Mar 25 14:49:39 2004 Subject: [Distutils] Re: build subcommand order References: <406334F7.nailY4119SB4@harold.colgate.edu> Message-ID: Dan Schult writes: > I have been using swig 1.3 along with distutils to make a package > and I'm having trouble with the subcommand order for "build". > The order is set at the bottom of command.build.py to be: > build_py > build_clibs > build_ext > build_scripts > > My problem is that swig gets run during build_ext and creates a > class definition in a new *.py file. That python file needs to > be moved into the staging area, but build_py doesn't find it > because it is created AFTER build_py is run. > > I propose a simple change of the order of the build commands > so that build_py is last. > > It is unlikely that build_py would make any actions that > affect the other command, but quite likely (especially given > the nature of Swig) that other actions may create > python files. > > I know one can always use: > python setup.py build_ext build_py > but I don't think every person that is packaging > (or unpackaging) a swig distribution should have to > document that --or figure it out. You can change the order in the setup script yourself. Here is what I do in one of them. This is because my build_py command already requires the extension modules built in build_ext: class my_build(build.build): # different order: build_ext *before* build_py, so that # build_py can already use ctypes! sub_commands = [('build_ext', build.build.has_ext_modules), ('build_py', build.build.has_pure_modules), ('build_clib', build.build.has_c_libraries), ('build_scripts', build.build.has_scripts), ] setup(name="ctypes", ext_modules = extensions, packages = packages, version="0.6.0", cmdclass = {'test': test, 'build_py': my_build_py, 'build': my_build }, **options ) Thomas From bob at redivi.com Thu Mar 25 14:53:05 2004 From: bob at redivi.com (Bob Ippolito) Date: Thu Mar 25 14:49:45 2004 Subject: [Distutils] [ANN] pkgdata In-Reply-To: <5.1.0.14.0.20040325143021.01eb2460@mail.telecommunity.com> References: <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> <5.1.0.14.0.20040325143021.01eb2460@mail.telecommunity.com> Message-ID: <07F5C058-7E96-11D8-BB21-000A95686CD8@redivi.com> On Mar 25, 2004, at 2:37 PM, Phillip J. Eby wrote: > At 01:28 PM 3/25/04 -0500, Bob Ippolito wrote: > >> On Mar 25, 2004, at 11:28 AM, Phillip J. Eby wrote: >> >>> At 11:11 AM 3/25/04 -0500, Bob Ippolito wrote: >>>> As per the BOF last night, here is the pkgdata module that I >>>> mentioned. Currently the only project using it is pygame. The >>>> "sys.datapath" mechanism that I talked about *could actually be >>>> implemented* on top of this system, supposing an appropriate >>>> adapter was written to support it! Remember: pkgdata is *just a >>>> hook*. It doesn't do anything other give the eventual option of >>>> doing something smarter than >>>> os.path.join(os.path.basedir(__file__), data). When you figure out >>>> what something smarter is, or you change your mind about what the >>>> smarter solution is (inside of an app bundle vs. system wide >>>> install, etc.), you don't have to refactor any of the code that >>>> uses pkgdata. >>> >>> Do you plan to support the PEP 302 'get_data()' facility? >> >> Probably not, I don't think anyone ever implemented it, and it seems >> more complicated than it needs to be. If someone really does use it, >> and thinks it should be implemented, please speak up. > > Perhaps I was unclear. What I meant was closer to, "why not expose > this functionality as methods on a __loader__ attribute of the module, > and update PEP 302 if needed?" Because import hooks are a pain, and this is simple. pkgdata also, intentionally, doesn't need to be standardized in Python. It uses protocolForURI and can (and should!) actually live inside every package that you use it from. > I'd love there to be a standard facility in Python for doing this, and > have it be supported for import-from-zip, py2exe, and all the other > possible routes to importing a module. As far as I'm aware, PEP 302 > is the only PEP that even vaguely touches on this, so it seems to make > sense to me to update it. That is a bit of a different problem. pkgdata solves the easy problem. If everyone starts using it, it will at least be possible to solve the hard problem, where the hard problem is intractable if all code keeps on using the "pragmatic" os.path.join(os.path.basedir(__file__), 'myfile') garbage. > As you probably know, PEAK has 'config.fileNearModule()' to do this, > but it doesn't have any mechanisms for dealing with non-file imports. > I intend to try to implement the PEP 302 route once I get around to > needing it. (Although, in all honesty I'm unlikely to embrace zipfile > imports until there's a way to use C extensions in them, at which > point it becomes a cool way to do simple binary installs of large > packages.) The way we do C extensions in a zip file on the Mac is to put a python shim in place of the extension, and load the extension from somewhere else. If you were to put the actual extension in the zip file, you would have to extract it to disk somewhere anyway because most dynamic linkers won't load objects that aren't files (although it seems like Mac OS X 10.4 will support this). If you're particularly interested, the extension shim file template is this: def __load(): import imp, sys, os for p in sys.path: path = os.path.join(p, "%(filename)s") if os.path.exists(path): break else: assert 0, "file not found: %(filename)s" mod = imp.load_dynamic("%(name)s", path) __load() del __load -bob From mal at egenix.com Thu Mar 25 14:53:03 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Mar 25 14:53:13 2004 Subject: [Distutils] build subcommand order In-Reply-To: <406334F7.nailY4119SB4@harold.colgate.edu> References: <406334F7.nailY4119SB4@harold.colgate.edu> Message-ID: <4063389F.3040203@egenix.com> Dan Schult wrote: > I have been using swig 1.3 along with distutils to make a package > and I'm having trouble with the subcommand order for "build". > The order is set at the bottom of command.build.py to be: > build_py > build_clibs > build_ext > build_scripts > > My problem is that swig gets run during build_ext and creates a > class definition in a new *.py file. That python file needs to > be moved into the staging area, but build_py doesn't find it > because it is created AFTER build_py is run. > > I propose a simple change of the order of the build commands > so that build_py is last. No. That would break other people's scripts. You can however, have distutils rerun the build_py script by calling: build_py = self.distribution.reinitialize('build_py') build_py.ensure_finalized() build_py.run() > It is unlikely that build_py would make any actions that > affect the other command, but quite likely (especially given > the nature of Swig) that other actions may create > python files. > > I know one can always use: > python setup.py build_ext build_py > but I don't think every person that is packaging > (or unpackaging) a swig distribution should have to > document that --or figure it out. > > If there is a better place to submit changes/improvements > please le me know. > > Thanks for a Great Package!! > Dan Schult > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 25 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 21 days left EuroPython 2004, G?teborg, Sweden 73 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Mar 25 14:58:27 2004 From: theller at python.net (Thomas Heller) Date: Thu Mar 25 14:58:37 2004 Subject: [Distutils] Re: [ANN] pkgdata References: <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> <3A85E6C4-7E8A-11D8-BB21-000A95686CD8@redivi.com> <5.1.0.14.0.20040325143021.01eb2460@mail.telecommunity.com> Message-ID: <7jx8aecc.fsf@python.net> "Phillip J. Eby" writes: > At 01:28 PM 3/25/04 -0500, Bob Ippolito wrote: > >>On Mar 25, 2004, at 11:28 AM, Phillip J. Eby wrote: >> >>>At 11:11 AM 3/25/04 -0500, Bob Ippolito wrote: >>>> As per the BOF last night, here is the pkgdata module that I >>>> mentioned. Currently the only project using it is pygame. The >>>> "sys.datapath" mechanism that I talked about *could actually be >>>> implemented* on top of this system, supposing an appropriate >>>> adapter was written to support it! Remember: pkgdata is *just a >>>> hook*. It doesn't do anything other give the eventual option of >>>> doing something smarter than >>>> os.path.join(os.path.basedir(__file__), data). When you figure >>>> out what something smarter is, or you change your mind about what >>>> the smarter solution is (inside of an app bundle vs. system wide >>>> install, etc.), you don't have to refactor any of the code that >>>> uses pkgdata. >>> >>>Do you plan to support the PEP 302 'get_data()' facility? >> >> Probably not, I don't think anyone ever implemented it, and it seems >> more complicated than it needs to be. If someone really does use >> it, and thinks it should be implemented, please speak up. > > Perhaps I was unclear. What I meant was closer to, "why not expose > this functionality as methods on a __loader__ attribute of the module, > and update PEP 302 if needed?" > > I'd love there to be a standard facility in Python for doing this, and > have it be supported for import-from-zip, py2exe, and all the other > possible routes to importing a module. As far as I'm aware, PEP 302 > is the only PEP that even vaguely touches on this, so it seems to make > sense to me to update it. I understand what you mean, and had exactly the same idea. I don't yet understand the code in Bob's package, probably because I never looked at PEAK any more than 5 or 10 minutes. What I understand (and that may be misunderstanding) is that it's a more or less abstract api to implement this functionality, and extend it later. I had a probably related idea, to implement a function like 'is_frozen' or so, which would return whether a script is executed as standard python script, or run frozen in an executable (py2exe, Installer, freeze, cx_freeze). This function should hide the exact details how this is determined, and be universally available. This way modules needing to know this (for example the COM registration code in win32all^H^H^H^H^H^H^H^Hpywin32) could use this function to customize its behaviour, with relying on internal details of py2exe or Installer. > As you probably know, PEAK has 'config.fileNearModule()' to do this, > but it doesn't have any mechanisms for dealing with non-file imports. > I intend to try to implement the PEP 302 route once I get around to > needing it. (Although, in all honesty I'm unlikely to embrace zipfile > imports until there's a way to use C extensions in them, at which > point it becomes a cool way to do simple binary installs of large > packages.) py2exe creates a pure Python loader for each extension module, which then dynamically loads it from the file system, without the need for the directory of the .pyds to be in sys.path. I don't think there is another way to load dlls on windows (except when you unpack them from the archive into the file system, and remove them later again - which I consider extremly ugly). Thomas From pje at telecommunity.com Thu Mar 25 15:27:54 2004 From: pje at telecommunity.com (Phillip J. Eby) Date: Thu Mar 25 15:22:09 2004 Subject: [Distutils] Re: [ANN] pkgdata In-Reply-To: <7jx8aecc.fsf@python.net> References: <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> <5.1.0.14.0.20040325112713.02160e60@mail.telecommunity.com> <3A85E6C4-7E8A-11D8-BB21-000A95686CD8@redivi.com> <5.1.0.14.0.20040325143021.01eb2460@mail.telecommunity.com> Message-ID: <5.1.0.14.0.20040325151944.03039c00@mail.telecommunity.com> At 08:58 PM 3/25/04 +0100, Thomas Heller wrote: >I had a probably related idea, to implement a function like 'is_frozen' >or so, which would return whether a script is executed as standard >python script, or run frozen in an executable (py2exe, Installer, >freeze, cx_freeze). This function should hide the exact details how >this is determined, and be universally available. This way modules >needing to know this (for example the COM registration code in >win32all^H^H^H^H^H^H^H^Hpywin32) could use this function to customize >its behaviour, with relying on internal details of py2exe or Installer. What I'm suggesting is that PEP 302 already provides a natural place for this to exist: the __loader__ method of a module. The module itself, or other modules, can then access loader facilities via that object if it exists, or use a fallback if not. And, if PEP 302 is ever "finished" (in the sense that the builtin Python import mechanism becomes part of the sys.metapath, then in theory we should also see a '__loader__' object available for normal modules. Indeed, the only thing stopping this from happening, I believe, is that nobody's implemented it. There's still probably a window in which it could be done for 2.4, and the resulting standardization would be a blessing, especially if coupled with "package data" installation support in distutils. From dschult at mail.colgate.edu Thu Mar 25 15:26:06 2004 From: dschult at mail.colgate.edu (Dan Schult) Date: Thu Mar 25 15:27:07 2004 Subject: [Distutils] Re: build subcommand order Message-ID: <4063405E.nailZC11VSUL@harold.colgate.edu> M.-A. Lemburg wrote: >Dan Schult wrote: >> I propose a simple change of the order of the build commands >> so that build_py is last. > >No. That would break other people's scripts. Can you think of one possible way that would break someone's script? A careful reading of build_py.py tells me it is just copying files... That should't affect build_ext, build_clibs or build_scripts... > >You can however, have distutils rerun the build_py script by >calling: > >build_py = self.distribution.reinitialize('build_py') >build_py.ensure_finalized() >build_py.run() > >-- >Marc-Andre Lemburg >eGenix.com I think I'm confused.... What is "self" supposed to refer to here? Where am I supposed to put these commands? Thanks for your quick response, Dan Schult From dschult at mail.colgate.edu Thu Mar 25 16:03:23 2004 From: dschult at mail.colgate.edu (Dan Schult) Date: Thu Mar 25 16:04:33 2004 Subject: [Distutils] build subcommand order Message-ID: <4063491B.nailZY2KQIHA@harold.colgate.edu> Thanks for the help--- I put in the cmdclass only {build: my_build} since I don't have a my_build_py. It works great! Still it seems that everyone using Swig to create packages will either have to run setup twice, or put this code in. Thanks again, Dan Schult From mal at egenix.com Thu Mar 25 16:10:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Mar 25 16:10:34 2004 Subject: [Distutils] build subcommand order In-Reply-To: <4063491B.nailZY2KQIHA@harold.colgate.edu> References: <4063491B.nailZY2KQIHA@harold.colgate.edu> Message-ID: <40634AC0.6010902@egenix.com> Dan Schult wrote: > Thanks for the help--- > I put in the cmdclass only {build: my_build} > since I don't have a my_build_py. > It works great! > > Still it seems that everyone using Swig to > create packages will either have to run > setup twice, or put this code in. Hmm, doesn't the existing SWIG support already add the Python module ? I know that SWIG support is very limited in distutils, but I would be surprised if it is that limited :-) (I'll have to deal with distutils + SWIG in the near future too.) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 25 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 21 days left EuroPython 2004, G?teborg, Sweden 73 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From theller at python.net Thu Mar 25 16:11:45 2004 From: theller at python.net (Thomas Heller) Date: Thu Mar 25 16:12:20 2004 Subject: [Distutils] Re: build subcommand order References: <4063491B.nailZY2KQIHA@harold.colgate.edu> Message-ID: Dan Schult writes: > Thanks for the help--- > I put in the cmdclass only {build: my_build} > since I don't have a my_build_py. > It works great! > > Still it seems that everyone using Swig to > create packages will either have to run > setup twice, or put this code in. Not everyone using SWIG lets it create Python classes, I think. SWIG support is generally very weak, it was only added to allow building the win32 extensions (which now really works!). Maybe this is a topic for another sprint ;-) Thomas From ZUJSYYJWVBJ at japan-net.ne.jp Thu Mar 25 18:37:48 2004 From: ZUJSYYJWVBJ at japan-net.ne.jp (Terry Abernathy) Date: Fri Mar 26 07:12:58 2004 Subject: [Distutils] Cash in with Google Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040325/8caf9495/attachment.html From jose at sferacarta.com Fri Mar 26 09:17:36 2004 From: jose at sferacarta.com (jose@sferacarta.com) Date: Fri Mar 26 09:17:23 2004 Subject: [Distutils] Encrypted document Message-ID: An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20040326/99c079e3/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: teabjhroie.bmp Type: image/bmp Size: 2026 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040326/99c079e3/teabjhroie-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: first_part.zip Type: application/octet-stream Size: 21714 bytes Desc: not available Url : http://mail.python.org/pipermail/distutils-sig/attachments/20040326/99c079e3/first_part-0001.obj From lars at ibp.de Fri Mar 26 09:19:20 2004 From: lars at ibp.de (Lars Immisch) Date: Fri Mar 26 09:20:59 2004 Subject: [Distutils] build subcommand order In-Reply-To: <40634AC0.6010902@egenix.com> References: <4063491B.nailZY2KQIHA@harold.colgate.edu> <40634AC0.6010902@egenix.com> Message-ID: <40643BE8.9090308@ibp.de> M.-A. Lemburg wrote: > Dan Schult wrote: > >> Thanks for the help--- >> I put in the cmdclass only {build: my_build} >> since I don't have a my_build_py. >> It works great! >> >> Still it seems that everyone using Swig to >> create packages will either have to run setup twice, or put this code >> in. > > > Hmm, doesn't the existing SWIG support already add the Python > module ? I don't think so. In the first place, swig should create .py files only if -shadow is passed, and I see no obvious support for this argument in the distutils code. I *might* be missing something obvious - at least Dan's setup must have created a .py file. > I know that SWIG support is very limited in distutils, but > I would be surprised if it is that limited :-) > > (I'll have to deal with distutils + SWIG in the near future too.) I think it is that limited. Swig is run without include path arguments (-Ifoo), macro definitions or undefs and only one possible extra argument (-cpp). Basically, swig is run as a side effect to build_ext. As Dan discovered, this is a problem in itself, since swig may generate Python code. I proposed a patch a week ago that addresses the missing arguments problem, but reuses the include_dirs, define_macros and undef_macros from the compilation stage. I am playing with a patch that makes build_ext a three-step process: - swig - compile - link with the additional options swig_include_dirs, swig_define_macros, swig_undef_macros and extra_swig_args. This doesn't solve Dan's problem, though. Maybe even this does not go far enough and swig could become an early step in the entire chain: build_swig build_py build_clibs build_ext build_scripts I believe this would require handling Swig extensions with a new Extension subclass, otherwise I couldn't see how depencies would be handled. But I haven't read enough distutils code yet. I'd be happy to hear other ideas. - Lars From dschult at mail.colgate.edu Fri Mar 26 14:35:52 2004 From: dschult at mail.colgate.edu (Dan Schult) Date: Fri Mar 26 14:37:32 2004 Subject: [Distutils] build subcommand order Message-ID: <40648618.nail1BP1AT34D@harold.colgate.edu> Lars Immisch wrote: >I don't think so. In the first place, swig should create .py files only >if -shadow is passed, and I see no obvious support for this argument in >the distutils code. > >Swig is run without include path arguments (-Ifoo), macro definitions or >undefs and only one possible extra argument (-cpp). Are you sure you have the latest version of Swig (and distutils)? It handles include directories just fine for me and it creates .py files by default (without -shadow) It seems that perhaps the best way to solve my problem is to add a line in build_ext.py that moves the python modules swig creates after it creates them. It sounds like you are having many more issues though... Dan From lars at ibp.de Fri Mar 26 16:42:43 2004 From: lars at ibp.de (Lars Immisch) Date: Fri Mar 26 16:43:53 2004 Subject: [Distutils] build subcommand order Message-ID: <4064A3D3.9020907@ibp.de> Dan Schult wrote: > Lars Immisch wrote: > >>I don't think so. In the first place, swig should create .py files only >>if -shadow is passed, and I see no obvious support for this argument in >>the distutils code. >> >>Swig is run without include path arguments (-Ifoo), macro definitions or >>undefs and only one possible extra argument (-cpp). > > > Are you sure you have the latest version of Swig > (and distutils)? Yes; I am using SWIG 1.3.21 (but my makefiles are from the days of SWIG 1.3.5). But you are right. Since SWIG 1.3.14, -shadow is default. See [1] below. > It handles include directories just fine for me > and it creates .py files by default (without -shadow) Do you have headers that are included via %include in the .i file (note %include instead of #include)? Standard #includes are just emitted to the wrapper code; the C compiler gets the right arguments and things just work (tm). The %includes are read by swig itself - swig takes the standard -I arguments, but they are not currently passed. (I need this to %include header files with type definitions that are later used by %typemaps or %extends.) > It seems that perhaps the best way to solve my problem > is to add a line in build_ext.py that moves the python > modules swig creates after it creates them. Sounds like a pragmatic solution to me. > It sounds like you are having many more issues though... Just extra arguments. I also find -modern quite important, but this could/should be handled by extra_swig_args. See [2]. - Lars From SWIG-1.3.21/CHANGES: [1] 07/23/2002: beazley *** IMPORTANT CHANGES TO THE PYTHON MODULE *** (1) The Python module now enables shadow/proxy classes by default. This means that two files are always created by SWIG. For instance, if you have this: // file: foo.i %module foo ... [2] 10/31/2003: beazley Incorporated patch: [ 829325 ] new Python Module options and features. Robin Dunn writes: This patch makes a number of changes to the SWIG python module. ... 5. Added a -modern command-line flag that will cause SWIG to omit the cruft in the proxy modules that allows it to work with versions of Python prior to 2.2. The result is a simpler, cleaner and faster python proxy module, but one that requires Python 2.2 or greater. From xml-admin at gnome.org Mon Mar 29 04:50:35 2004 From: xml-admin at gnome.org (xml-admin@gnome.org) Date: Mon Mar 29 04:52:09 2004 Subject: [Distutils] Your message to xml awaits moderator approval Message-ID: <20040329095035.1428.53488.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: 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 virencheck at repas-aeg.de Mon Mar 29 14:33:29 2004 From: virencheck at repas-aeg.de (virencheck@repas-aeg.de) Date: Mon Mar 29 07:34:55 2004 Subject: [Distutils] Virenchecker Information Message-ID: <200403291233.i2TCXnL10042@mail02.repas.de> Dies ist eine automatisch generierte Meldung - auto-generated email . Die Mail mit folgenden Eigenschaften - original mail header : Subjekt : Failed (tegge@repas-aeg.de) Absender / from: Empfänger / to : Path : Received: from unknown(221.136.132.123) by mail02 via smap (V2.1) id xma009988; Mon, 29 Mar 04 14:32:57 +0200 wurde nicht weitergeleitet, da sie vermutlich ein oder mehrere Attachment[s] mit potentiell gefährlich eingestufter Extension enthält! Our mail filter rejected this transaction, because of potentially dangerous attachments Für die Bewertung relevanter Abschnitt - reason causing rejection : <1> name="message.pif" From gnome-doc-list-admin at gnome.org Wed Mar 31 03:56:08 2004 From: gnome-doc-list-admin at gnome.org (gnome-doc-list-admin@gnome.org) Date: Wed Mar 31 03:56:12 2004 Subject: [Distutils] Your message to gnome-doc-list awaits moderator approval Message-ID: <20040331085608.21118.69389.Mailman@moniker.gnome.org> Your mail to 'gnome-doc-list' with the subject Failure (docs@gnome.org) 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.