setup.py is too aggressive
It seems to me setup.py tries to build libraries even when it's impossible E.g., I had to add the patch attached so I will get no more ImportErrors where the module shouts at me that it could not find a symbol.
The more general problem here is that building of a module may fail: Even if a library is detected correctly, it might be that additional libraries are needed. In some cases, it helps to put the correct module line into Modules/Setup (which would have helped in your case); then setup.py will not attempt to build the module. However, there may be cases where a module cannot be build at all: either some libraries are missing, or the module won't work on the system for some other reason (e.g. since the system library it relies on has some bug). There should be a mechanism to tell setup.py not to build a module at all. Since it is looking into Modules/Setup anyway, perhaps a *excluded* dbm syntax in Modules/Setup would be appropriate? Of course, makesetup needs to be taught such a syntax. Alternatively, an additional configuration file or command line options might work. In any case, distributors are certainly advised to run the testsuite and potentially remove or fix modules for which the tests fail. Regards, Martin
On Sat, 24 Mar 2001, Martin von Loewis <loewis@informatik.hu-berlin.de> wrote:
In any case, distributors are certainly advised to run the testsuite and potentially remove or fix modules for which the tests fail.
These, however, aren't flagged as failures -- they're flagged as ImportErrors which are ignored during tests -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
In any case, distributors are certainly advised to run the testsuite and potentially remove or fix modules for which the tests fail.
These, however, aren't flagged as failures -- they're flagged as ImportErrors which are ignored during tests
I see. Is it safe to say, for all modules in the core, that importing them has no "dangerous" side effect? In that case, setup.py could attempt to import them after they've been build, and delete the ones that fail to import. Of course, that would also delete modules where setting LD_LIBRARY_PATH might cure the problem... Regards, Martin
On Sat, 24 Mar 2001, Martin von Loewis <loewis@informatik.hu-berlin.de> wrote:
I see. Is it safe to say, for all modules in the core, that importing them has no "dangerous" side effect? In that case, setup.py could attempt to import them after they've been build, and delete the ones that fail to import. Of course, that would also delete modules where setting LD_LIBRARY_PATH might cure the problem...
So people who build will have to set LD_LIB_PATH too. I don't see a problem with that... (particularily since this will mean only that if the tests pass, only modules which were tested will be installed, theoretically...) -- "I'll be ex-DPL soon anyway so I'm |LUKE: Is Perl better than Python? looking for someplace else to grab power."|YODA: No...no... no. Quicker, -- Wichert Akkerman (on debian-private)| easier, more seductive. For public key, finger moshez@debian.org |http://www.{python,debian,gnu}.org
On 24 March 2001, Martin von Loewis said:
There should be a mechanism to tell setup.py not to build a module at all. Since it is looking into Modules/Setup anyway, perhaps a
*excluded* dbm
syntax in Modules/Setup would be appropriate? Of course, makesetup needs to be taught such a syntax. Alternatively, an additional configuration file or command line options might work.
FWIW, any new "Setup" syntax would also have to be taught to the 'read_setup_file()' function in distutils.extension. Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ We have always been at war with Oceania.
participants (3)
-
Greg Ward -
Martin von Loewis -
Moshe Zadka