Le 16/07/2012 13:04, Picca Frédéric-Emmanuel a écrit : >> I just did a: >> python$* /usr/bin/scons > > > So we just need to configure with the right python$* version and that's all.
Yes, that problem is solved :-) > I agreed the upstream logic is important. other projects relying on > cctbx must find what they are expecting. We do not intend to > create a fork of cctbx :). OK, so I'll put this "boost" package into the python path (probably using a .pth file). If the Boost project ever releases a python extension, we'll worry about it then. > I do not yet understand what the problem is all about. Is it possible > to put a clear explaination of the problem into the wiki. Then it will > be possible to take decisions and speak with the upstream. > For me the python module and extension must be installed the Debian way > on the system. Then thoses modules should be called like the upstream > did in other scripts. I thought about it more, and I think I created the problem myself :-) Upstream import the extensions a little bit differently from the typical python project. Usually, extensions .so files are located inside the package directory where they belong. In cctbx, all .so file are in a lib directory, which is added to PYTHONPATH (even though the .so are not meant to be imported directly by the users), and then an import stub imports the objects to their final place. At first, without much thinking, I did the usual python way and moved the .so files into the packages. But in fact, there is nothing broken in letting them in the python path (apart from a small namespace pollution, but that doesn't justify diverging from upstream). So I'll just install them in the python path and the problem is solved. I just updated the wiki for reference. Cheers, Baptiste -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
