[Distutils] distutils and mxDateTime

[Greg Ward]

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?).

> · 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.

> · 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.

> · 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.

>   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.

>   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*).

        Greg