[Distutils] Patch for new install options

[Greg Ward]

On 25 April 2000, Harry Henry Gebel said:
> It doesn't look like I will be done with bdist_rpm tonight, here is the
> patch for the now install options; they are both intended to be run by RPM
> or other packaging systems from within a .spec file (or equivalent)
> (although the RPM process may have been launched by another setup.py) Some
> things I would like different:

I'm not sure I entirely agree with the method this patch.  To summarize,
for those who didn't take 5 or 10 minutes to read the patch (and 3
months to understand what's going on in distutils.command.install ;-),
Harry's patch adds this capability (as I understand it):

  * when you run "setup.py install --record-install", it installs
    as usual and writes the list of files installed to INSTALLED_FILES
    in the current directory

  * when you run "setup.py install --package-prefix=/tmp --record-install",
    then it installs to (eg.) /tmp/usr/lib/python1.5/site-packages,
    and writes the installed filenames -- minus the "/tmp/" prefix --
    to INSTALLED_FILES

It's the addition of another, somewhat artifical, installation scheme
that bothers me about this.  I'm also not keen on adding yet another
type of "base directory" -- we already have "install_base", "prefix",
"exec_prefix", and "home", and now you want to add "root" which is
sometimes stuck in ahead of the "install_base".  Ugh.

Now, the goal is noble: do an installation that looks exactly like what
the RPM you're creating will install, except it's not actually in the
live Python installation.  There's no obvious way to do this with
Distutils as it stands, because if you supply --prefix, you have to
supply the whole thing -- "/usr/local" or "/tmp/usr" or "/tmp/usr/local"
or whatever you want.  What you want is a "meta-prefix", which you
called the "package prefix" or "root".

[...some time passes...]

OK, I think I've got it.  I've generalized the notion of "configuration
variables" to work on the command line, at least the command line of the
"install" command.  (Config variables will be very important when we
start dealing with config files, but they're still useful on the command
line.  They're even used in the Distutils code: if anyone has looked at
the INSTALL_SCHEMES dictionary in install.py, I was *not* smoking drugs,
Perl or otherwise, when I wrote that code.  They're called configuration
variables, and I borrowed the shell/perl syntax because it works.  So
there.)

Anyways, the idea is this: if you want to do a fake install prior to
creating an RPM (or what-have-you), you can do this:

    ./setup.py -n install \
      --prefix='/tmp$sys_prefix' --exec-prefix='/tmp$sys_exec_prefix'

...and that does more or less what you might expect.  Update your
Distutils to the latest CVS -- I'll check this change in shortly -- to
see what I mean.

Oh, damn!  I just remembered that I've already sorta-kinda solved this
problem, for the "bdist_dumb" command.  There, I did it all in Python
code, since there's no need to put shell command in a spec file that
will be run later -- so I think the above trick might still be needed
for building RPMs.  Plus, it's just plain cool, so I think it'll stay
unless/until someone thinks of a better way.

BTW, the "install" command as I am about to check it in will spew lots
of debugging output at you.  This is a feature.  Please read the output
and see if you can grok the latest madness escaping from my fevered
imagination.  Wouldn't hurt to read the code -- 'finalize_options()' in
install.py -- if that's your poison.

Brain hurts... off to bed...

        Greg
-- 
Greg Ward - just another /P(erl|ython)/ hacker          gward@python.net
http://starship.python.net/~gward/
MTV -- get off the air!
    -- Dead Kennedys