bugBKChem - Bugs: bug #19925, Pathname problems in bin/bkchem...


bug #19925: Pathname problems in bin/bkchem wrapper

Submitter:  Daniel Macks <dmacks>
Submitted:  Tue 22 May 2007 05:19:34 AM UTC
Category:  None Severity:  3 - Normal
Item Group:  installation Status:  Postponed
Privacy:  Public Assigned to:  beda
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Tue 29 May 2007 10:47:18 AM UTC, comment #5: 

>> But if a packge does special things other than just compile .so and copy .py files, it's up to the local implementation of those actions to follow the standard behaviors

I agree that it is important for the packages to follow the standard behavior for the particular distribution they are targeting, but this is something the packager should take care of, not the author.
The fact that Debian is using the --root option during the packaging or installation or whatever does not by any means set a standard for the behavior of the --root option in general. I cannot assume that when a user uses the --root option, he is not in fact installing into a different root, but just using it as a temp directory. This would break the installation process for those who use --root in the way that it was intended.
However the problem has an easy solution. There is the "--strip" option to the setup.py, that I have added specifically to address the problem of packaging. When you set --strip=/tmp/ the prefix "/tmp/" will be removed from all the absolute paths that appear in bkchem startup script and the site_config.py
When you set --root and --strip to the same path, you should get the desired behavior.
I hope that this would help. I will try to solve the python interpreter name problem in a similar manner.

Beda Kosata <beda>
Group administrator
Tue 29 May 2007 08:31:45 AM UTC, comment #4: 

Here's a simple example distutils from python2.4 that demonstrates the standard behavior of a python module being installed at $root/$prefix for ultimate use from $prefix

% cat setup.py
from distutils.core import setup
setup(name="foo", version="1.0", py_modules=["foo"])

%  python setup.py install --prefix=/tmp/foo1 --root=/tmp/foo2
running install
running build
running build_py
creating build
creating build/lib
copying foo.py -> build/lib
running install_lib
creating /tmp/foo2
creating /tmp/foo2/tmp
creating /tmp/foo2/tmp/foo1
creating /tmp/foo2/tmp/foo1/lib
creating /tmp/foo2/tmp/foo1/lib/python2.4
creating /tmp/foo2/tmp/foo1/lib/python2.4/site-packages
copying build/lib/foo.py -> /tmp/foo2/tmp/foo1/lib/python2.4/site-packages
byte-compiling /tmp/foo2/tmp/foo1/lib/python2.4/site-packages/foo.py to foo.pyc

% strings /tmp/foo2/tmp/foo1/lib/python2.4/site-packages/foo.pyc

Daniel Macks <dmacks>
Tue 29 May 2007 08:22:57 AM UTC, comment #3: 

Here's Debian's instructions for creating a python-modules pacakge:


in which --root is used to create a temporary installation location for a module that will "actually" be run from the normal prefix. Every python module that uses distutils does behave in the same way: --prefix is the actual runtime location, --root is a temp install location. But if a packge does special things other than just compile .so and copy .py files, it's up to the local implementation of those actions to follow the standard behaviors.

Daniel Macks <dmacks>
Tue 29 May 2007 07:34:37 AM UTC, comment #2: 

Thanks for submitting a bug report. Unfortunately I am not sure if this is in fact a bug. I don't think that the described behavior is in conflict with what the help says:

--prefix installation prefix
--root install everything relative to this alternate root directory

As I understand it, --root has nothing to do with temporary install location as you mentioned. IMHO --root simply replaces what would normally be "/" with something you specify. The prefix then describes the relative location inside the root where the different directories should be created.
This is in agreement with what you got.
BTW all the help messages, processing of options etc. is done by Pythons distutils and I don't modify it in any way. This means that every Python program using distutils would behave this way, regardless of what you or I might consider right.
I agree that there should be some option that would enable users to modify the python interpreter name. On the other hand, I don't think that the install process should somehow deduce it from the command used to run the install process. I will add some command-line option to enable this instead.

Beda Kosata <beda>
Group administrator
Tue 22 May 2007 05:36:08 AM UTC, comment #1: 

Actually, the whole installed site_config.py file is similarly broken with respect to listing the --root pathnames instead of using --prefix. To quote 'python setup.py install --help':

  --prefix            installation prefix
  --root              install everything relative to this alternate root directory

Daniel Macks <dmacks>
Tue 22 May 2007 05:19:34 AM UTC, original submission:  

My python interpretter is not called "python" and it's not in my shell PATH variable, so I pass its full pathname as part of setup.py:

/sw/bin/python2.4 setup.py build --prefix=/sw

However, that interp path is not propagated into the bin/bkchem wrapper script:

python /sw/build/root-bkchem-0.12.0pre2-1/sw/lib/python2.4/site-packages/bkchem/bkchem.py "$@"

That wrapper was installed with:

/sw/bin/python2.4 setup.py install --root=/sw/build/root-bkchem-0.12.0pre2-1

So why does it think the lib is installed in the --root path, which is documented as a temp install location, instead of the --prefix runtime location?

Daniel Macks <dmacks>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by beda (Updated the item)
  • -email is unavailable- added by dmacks (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-05-29 beda StatusIn Progress Postponed
    2007-05-23 beda StatusNone In Progress
        Assigned toNone beda

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code