If you are installing from .../bin/foo to /usr/local/bin/foo, distutils installs correctly, but then reports an error when it incorrectly tries to chmod the file /usr/local/bin/bin/foo . The problem seems to be in .../distutils/cmd.py, in the function _copy_files(). It looks as if it should not just do os.path.join, but should drop off the directory parts of f, first with os.path.basename(). setup.py: from distutils.core import setup setup(name="promu1python", version="1.0", description = "Stem-ML level 1 tag set", author = "Greg Kochanski", author_email = "gpk@bell-labs.com", url="http://hce.research.bell-labs.com/promu1python", scripts = ["bin/promu1.sh"], packages = ["promu1python"])
On 02 June 2000, Greg Kochanski said:
If you are installing from .../bin/foo to /usr/local/bin/foo, distutils installs correctly, but then reports an error when it incorrectly tries to chmod the file /usr/local/bin/bin/foo .
The problem seems to be in .../distutils/cmd.py, in the function _copy_files(). It looks as if it should not just do os.path.join, but should drop off the directory parts of f, first with os.path.basename().
I can't reproduce this. If you're referring to the '_copy_files()' method in install_misc, it can't be that, because that class isn't (currently) used anywhere. Can you tell us which Distutils version you're using, which version of Python, and which OS? And show us exactly the command(s) issued and the complete output you got? I can't reach your web site right now; if I could I'd try to go download your tarball and try it myself. If it's no more than 50k, can you mail it directly to me (gward@python.net)? Thanks... Greg -- Greg Ward - geek-at-large gward@python.net http://starship.python.net/~gward/ Just because you're paranoid doesn't mean they *aren't* out to get you.
Hello, 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. Another bug I found: When I run # python setup.py sdist bdist_rpm I get the following traceback: [snipped] running bdist_rpm writing 'build/bdist.linux2-i686/rpm/SPECS/linkchecker.spec' Traceback (innermost last): File "setup.py", line 100, in ? data_files = [('locale/de/LC_MESSAGES', File "/usr/lib/python1.5/site-packages/distutils/core.py", line 111, in setup dist.run_commands () File "setup.py", line 32, in run_commands self.run_command (cmd) File "/usr/lib/python1.5/site-packages/distutils/dist.py", line 757, in run_command cmd_obj.run () File "/usr/lib/python1.5/site-packages/distutils/command/bdist_rpm.py", line 290, in run source = sdist.get_archive_files()[0] TypeError: unsubscriptable object 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. Bastian
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.
participants (3)
-
Bastian Kleineidam -
Greg Kochanski -
Greg Ward