Passing in arguments to Distribution?
I maintain the (rather large) PyOpenGL project, which is basically 4 core modules plus 300+ extension modules. One of the features I'd like to allow for developers is to specify that, for instance, only 1 of the extension modules be rebuilt during a setup pass (particularly during development, it can take 3 or 4 minutes just to run the configs for all the modules, which makes for very slow development).
The way the code currently works is that we override the Distribution object's "finalize_options" to search out all of the .i (SWIG) files in the interface sub-directory, creating an Extension object for each one we find.
What I'd like to do is to tell the code running in the Distribution to look for a global option (--extensions, for instance) and if it's present, restrict the set of Extensions that's being built to the list in the option.
However, I don't see a clean way of passing in arguments to the Distribution object itself. It seems to be responsible for the parsing of the command line, but it assumes that it's trying to parse options for a particular command rather than for the overall process.
Any recipes someone cares to share? At the moment I'm thinking I may just parse the options myself using getopt, but that seems like it might cause pain somewhere down the road. I'm going to keep experimenting to see if I can hack something in, but this seems like it would be a common requirement, so I would imagine there's a lever somewhere I can throw...
At the moment I'm thinking of moving the module discovery code into the main setup script, but that's still going to require parsing the options myself... and that seems wrong somehow...
Where-do-I-stand-and-on-what-do-I-pull-ly yr's, Mike
On Sunday 21 November 2004 15:17, Mike C. Fletcher wrote:
Any recipes someone cares to share? At the moment I'm thinking I may just parse the options myself using getopt, but that seems like it might cause pain somewhere down the road. I'm going to keep experimenting to see if I can hack something in, but this seems like it would be a common requirement, so I would imagine there's a lever somewhere I can throw...
4suite's latest alpha provides an interesting approach--though I won't come right out and vouch for it because I'm trying to spec an RPM but it doesn't have the --record option--where they allow for sub-packages. This allows one to operate on only certain sub-packages for building, installing, etc. Although PackageManager provides for this, it constitutes as a fork of the mainstream distutils and as such there will be differences or even missing features (--record).
Anyway, seeing how it operates is beneficial for both discussion and potential py2.5 inclusion...
take care,
On Sunday 21 November 2004 12:36 am, Jeff Pitman wrote:
On Sunday 21 November 2004 15:17, Mike C. Fletcher wrote:
Any recipes someone cares to share? At the moment I'm thinking I may just parse the options myself using getopt, but that seems like it might cause pain somewhere down the road. I'm going to keep experimenting to see if I can hack something in, but this seems like it would be a common requirement, so I would imagine there's a lever somewhere I can throw...
4suite's latest alpha provides an interesting approach--though I won't come right out and vouch for it because I'm trying to spec an RPM but it doesn't have the --record option--where they allow for sub-packages. This allows one to operate on only certain sub-packages for building, installing, etc. Although PackageManager provides for this, it constitutes as a fork of the mainstream distutils and as such there will be differences or even missing features (--record).
Anyway, seeing how it operates is beneficial for both discussion and potential py2.5 inclusion...
take care,
I'm curious as to why the --record option is even needed (as I removed it on purpose). 4Suite's bdist_rpm command does all the work for determining which files need to be included. Did you happen to look at the spec file produced by 4Suite? Is it missing something we should be aware of?
At 12:49 AM 11/21/04 -0700, Jeremy Kloth wrote:
I'm curious as to why the --record option is even needed (as I removed it on purpose).
Please don't break '--record'. I use it to automatically generate a PLIST file for the NetBSD packaging system.
Not everybody uses RPMs, and I wouldn't be surprised if there are other people who use '--record' to interface with other packaging systems.
Phillip J. Eby wrote:
At 12:49 AM 11/21/04 -0700, Jeremy Kloth wrote:
I'm curious as to why the --record option is even needed (as I removed it on purpose).
Please don't break '--record'. I use it to automatically generate a PLIST file for the NetBSD packaging system.
Not everybody uses RPMs, and I wouldn't be surprised if there are other people who use '--record' to interface with other packaging systems.
I don't think anyone is considering removing --record from main line distutils. The discussion was about a fork of the distutils package.
As for the original question on how to pass in parameters:
I don't really understand what Mike is trying to do. Adding new options to Distribution is certainly possible and accessing those new options just as well. It is also possible to pass parameters into its subcommands and having them reinit themselves (e.g. to trim down the list of Extension objects; even though it's easier to do from a build_ext subclass).
On Sunday 21 November 2004 15:49, Jeremy Kloth wrote:
Did you happen to look at the spec file produced by 4Suite? Is it missing something we should be aware of?
Directories. I'm building a repo of py stuff and just had a spec template. But, when done differently, I have to rely on other methods. Though, I'm more inclined to rely on distutils than rolling my own RPMs. However, directories being left on the disk after uninstall and trying to implement other policies is a bit difficult.
participants (5)
-
Jeff Pitman -
Jeremy Kloth -
M.-A. Lemburg -
Mike C. Fletcher -
Phillip J. Eby