Re: Opening up backdoors to 'setup()'
[quoth Amos]
So distutils.core.setup(script_name=file, script_args=commands) is the same as distutils.core.run_setup(file, commands)?
No. Passing 'script_name' to 'setup()' is just a "fool yourself" thing; it doesn't actually change the script being run. It's mainly there for completism's sake; if you can override sys.argv[1:], you ought to be able to override sys.argv[0]. Here's a summary of what I'm thinking right now: setup(var=value, ...) - the traditional and usual way to invoke the Distutils - parses sys.argv (unless you override it) and carries out all actions implied by the command line and config files - currently returns nothing -- not much point, because it's all about side-effect, and the intended use is from a setup script, which is run by an installer who doesn't give a whit about the Distribution instance run_setup(file, script_args=sys.argv[1:], stop_after="run") - execfile's the setup script named by 'file' - this causes 'setup()' to be called in the normal way, so that a Distribution instance is created in the normal way, etc. - but some strings are pulled behind the scenes so that we don't necessarily run to completion - and something -- probably the Distribution instance -- is returned, which the caller can than query to discover the state of the distribution (eg. metadata, contents of config files, etc.)
If so, is there any need for a run_setup function?
I still think so. The differences are subtle but important. Greg -- Greg Ward - Unix geek gward@python.net http://starship.python.net/~gward/ "He's dead, Jim. You get his tricorder and I'll grab his wallet."
Just to be clear, I do not have any "script" I want to run. The call to setup is "it". I am doing something like apply(setup, [], kw) having set up the dictionary kw. I do not have a file and don't want to write one. My problem was how to specify the command and its arguments in this context. That could be one or more extra keyworded arguments, or it could be positional argument(s), since normally setup doesn't have any. I morally object to stuffing sys.argv, is all. So far, by the way, I have not encountered a single user who was not completely and utterly mystified by the traceback, which as a nice side effect generally caused the compile error they needed to see to scroll off screen. I think as a long term goal we should be trapping all errors inside setup and uttering something intelligent. The fact that one is in the call to setup is not exactly illuminating. Perhaps I missed a discussion of this sort since I can't really handle this lists' volume. If so, my apologies.
On 29 August 2000, Paul F. Dubois said:
Just to be clear, I do not have any "script" I want to run. The call to setup is "it". I am doing something like apply(setup, [], kw) having set up the dictionary kw. I do not have a file and don't want to write one.
Right, that's what I understood. You don't have to write a file at all, all you have to do is add a 'script_args' element to your 'kw' dict to override sys.argv[1:]. For good form, you might need to add 'script_name' to override sys.argv[0]. This matters in two places: the "build_py" command excludes 'script_name' when it does *.py to find all modules in a package, to prevent the setup script being installed; and the "sdist" command regenerates the MANIFEST file if it is older than 'script_name', on the theory that you may have added or removed modules if you edited your setup script. The business about a file to run is for Amos, who wants to pull random setup scripts off the net and extract useful information from them. The clean-looking way to do this is to pass the filename (of the setup script) into the Distutils and ask it to do the dirty work for you.
So far, by the way, I have not encountered a single user who was not completely and utterly mystified by the traceback, which as a nice side effect generally caused the compile error they needed to see to scroll off screen.
Huh? Which traceback are you talking about here? Any traceback from a setup script is a bug in the Distutils (unless it's custom code in the setup script, can't do much about that). Any "user" errors -- either by the installer or the developer who wrote the setup script -- *are* caught by 'setup()'; failure to catch such errors is a Distutils bug and should be treated as such. Greg
participants (3)
-
Greg Ward -
Greg Ward -
Paul F. Dubois