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

 
 

bug #19925: Pathname problems in bin/bkchem wrapper

Submitted by:  Daniel Macks <dmacks>
Submitted on:  Tue 22 May 2007 05:19:34 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: installationStatus: Postponed
Privacy: PublicAssigned to: Beda Kosata <beda>
Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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
/tmp/foo1/lib/python2.4/site-packages/foo.pyt

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:

http://wiki.debian.org/DebianPython/NewPolicy#head-361ba69b3cd19d9b6bab84fbac6099268ddb3366

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>
Project AdministratorIn charge of this item.
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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 29 May 2007 07:34:37 AM UTCbedaStatusIn Progress=>Postponed
    Wed 23 May 2007 12:37:54 PM UTCbedaStatusNone=>In Progress
      Assigned toNone=>beda

    Back to the top


    Powered by Savane 3.1-cleanup