[Distutils] two bugs

[Greg Ward]

On 03 June 2000, Bastian Kleineidam said:
> I discovered a minor glitch in install_data.py, line 59, in
> get_outputs(self):
> replace
>         return self.outfiles
> with
>         return self.outfiles or []
> to ensure a list is returned and not the None object.

Yup, fixed.  Thanks.

> Another bug I found:
> Here is why:
> bdist_rpm.py:283:  sdist = self.reinitialize_command ('sdist')
> now sdist is _not_ finalized
> bdist_rpm.py:288:  self.run_command('sdist')
> now sdist is _still_ not finalized! this is because we have run
> 'sdist' before and wrote this in the cache:
> dist.py:751: if self.have_run.get (command):
>                  return
> and therefore sdist.get_archive_files() returns None which is not
> subscriptable
> 
> I have no fix for this bug. Probly you should insert
> in Distribution.reinitialize_command() the line
> self.have_run[commandname] = 0
> before the return.

Coincidentally, I fixed that bug last night, before I carefully read
your bug report.  Your fix is correct, which becomes obvious when you
realize that command objects have a fairly strict life-cycle; the
'reinitialize_command()' method is (so far) the only way to go backwards
in that life-cycle, and the state was not being properly set to reflect
that backwards transition.  So this should be working in the current
CVS.

Incidentally, I fixed it so that the "bdist" command can take multiple
formats, eg. "bdist --formats=zip,gztar", and run the same "bdist_*"
command ("bdist_dumb") in this case multiple times.

Be aware that in the "setup.py sdist bdist_rpm" case, "sdist" will run
twice: once at your behest, and once at the behest of "bdist_rpm".  This
looks wasteful, but it's the only safe way to operate, as "bdist_rpm"
might set options on "sdist" that cause it to behave differently.
(Well, OK, we could have a "have run with this particular state" cache,
but that seems excessive.)

BTW, you should be aware that I am 99% decided to change the base
installation directory from "<prefix>/share" to just plain "<prefix>".
Now that you can put data files wherever you please, prefix seems like
the logical place to put them; if you wish to conform to the GNU
standards, all you have to do is change (eg.) "locale/de" to
"share/locale/de" in the setup script.  But if you have "data" files
that belong in "lib" or "etc", you can easily put them there, too.

(Unix bias?  What do you mean, I have a Unix bias?  ;-)

        Greg
-- 
Greg Ward - Unix geek                                   gward@python.net
http://starship.python.net/~gward/
God made machine language; all the rest is the work of man.