[Distutils] distutils and mxDateTime

[M.-A. Lemburg]

Greg Ward wrote:
> 
> On 25 January 2000, M.-A. Lemburg said:
> > · The setup.py file does print a help screen, but does not
> >   tell the user which commands are available. I think this
> >   should be done to help the overloaded sysadmin ;-)
> 
> You're not the first to ask.  I'll see if I can squeeze that into
> version 0.1.3 (this weekend perhaps?).

Cool.
 
> > · I found that using a file layout like this:
> >
> >   setup.py
> >   DateTime/
> >
> >   does not work... how do I have to fix setup.py to work
> >   in this situation (setup.py being outside the package dir) ?
> 
> I assume you're using the mxdatetime_setup.py included in the Distutils
> distribution, in which case you have the following two options:
> 
>        packages = ['DateTime', 'DateTime.Examples', 'DateTime.mxDateTime'],
>        package_dir = {'DateTime': ''},
> 
> Short answer: delete 'package_dir'.
> 
> Long answer: by putting the DateTime package in the DateTime directory,
> you are doing the "preferred thing" and thus don't have to tell
> Distutils where to find your .py source files.  The version of
> mxDateTime I based the setup script on had the DateTime package in the
> distribution root (the current directory, or ''), so I had to tell
> Distutils to look there for it -- that's what the 'package_dir' option
> is for.

Ah, ok.
 
> > · Tracebacks are nice for debugging, but not so nice for
> >   the end user. I'd suggest to only print tracebacks when
> >   setup.py is run in -d mode and otherwise only output
> >   a single line explaining the error condition (and via
> >   some dictionary the possible solution to the problem).
> 
> <sarcasm>
> Hey, as long as version < 1.0, you're in debugging mode whether you like
> it or not.
> </sarcasm>
> 
> I'm not sure that a "debugging mode" flag is the answer.  If the
> exception is due to an error in the code (Distutils code *or* a
> custom/extended command class), that's a bug and there should always be
> a traceback.  If the exception is due to user error, there should never
> be a traceback and the presence of one is a bug.  I know there are many
> exceptions that should be turned into a simple one-line "augh! user
> error, die" termination, but still show tracebacks.  Nevertheless, you
> can keep me honest by reporting these as bugs when you see them.

Well, if it's a bug, the user can run setup.py in -d mode
and then extract the traceback. It is just that user
errors producing those deeply nested tracebacks will keep
users from even thinking that they made a mistake ;-)

> > · For many of my packages the user will have to edit a
> >   Setup file and change paths and/or compile time defines.
> >   How can this be done using setup.py ?
> 
> It can't (yet), short of forcing users the edit the setup script.  (Oh
> yeah, now I remember why I haven't been pressing you to Distutil-ize
> mxDateTime...)  I think the right thing to do is have config files; same
> idea as the old-style Setup file, but more structured.

You mean a setup.py file containing Python code plus a
config.ini file for the user adjustments. Sounds fine to
me... In that case I'd like an option on setup.py which
allows me to preedit the config.ini file via a Python
module, something like "setup.py --boot" which then 
calls a function defined in setup.py to preprocess config.ini.
 
This function could also do the interactive part I mentioned
below, BTW.

> >   I think I'd like
> >   this procedure to either be semi-automatic (a setdefaults.py
> >   module would scan the system and set the switches) or
> >   interactive with the user entering paths and answering
> >   to questions like:
> >
> >   Do you want to setup the subpackage mx.ODBC.Sybase ? [y/n]
> 
> At the risk of sounding dogmatic, my initial reaction to interactive
> installation is "Absolutely out of the question!".  Serial Q&A is not a
> user interface model I wish to perpetrate or inflict on anyone.

Doesn't matter, I want it anyway ;-) Note that it doesn't
have to be tty based: a nice colorful installer could take
care of this part.

Seriously, given the above setup.py + config.ini file configuration
the interactive parts could be coded in the boot function. Would
be nice if there were an option --interactive, -i which enables
a switch to do interactive setup usable by the boot function.
 
> >   I guess
> >   this can only be done by creating the setup.py:setup()
> >   call parameters on-the-fly...
> 
> Hmmm, you've been drinking from the cup of PyFort (which generates a
> setup script based on a Fortan-ish description of Fortran subroutines
> that will be glued into Python via generated C code... *shudder*).

Provided we find a good intergration of the config.ini
data with the setup() call parameters, this may not be as
bad as expected.

-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/