[Distutils] Patch for new install options

[Mark W. Alexander]

Ok, I'm jumping in late but, what the hell, here goes
both feet.

If I'm following the --package-prefix theme properly, it's
very much in line with RPM's BUILDROOT, and install tree
used for 2 very important reasons. First, the package
builder need not be root to produce a binary package
that installs in directories that only root can write
to. Second, it provides for relocatable binary RPM's.

I consider the first helpfull, the second mandatory. If
I have several machines with different disk partitioning
schemes, I want to be able to install the same RPM's on
all of them, even if I have to relocate some modules
(or even the entire Python tree) and install time.
The manual way I've been doing packages (not RPM's,
but Solaris pkgs and HP-UX depots), I have the pre-
install scripts find the Python install location and
automatically relocate to there. (User can override,
of course.)

Again, I haven't come up to speed yet, but the addition
of a "temporary" install tree is far from artificial.
Simply being able to test your packaging process without
stepping on your production distribution is worth what
little effort is required to support it.

While I'm still catching up here: Has anyone stepped up
to do either Solaris bdist-pkgtool or HP-UX bdist-depot?
If not, it looks like a good way for me to start wading
in.

Mark Alexander
mwa@gate.net


On Tue, 25 Apr 2000, Greg Ward wrote:

> Date: Tue, 25 Apr 2000 22:22:58 -0400
> From: Greg Ward <gward@ase.com>
> To: distutils-sig@python.org
> Subject: Re: [Distutils] Patch for new install options
> 
> 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
> 
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> http://www.python.org/mailman/listinfo/distutils-sig
>