[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cctbx debian package

On Mon, 16 Jul 2012 14:37:55 +0200
Baptiste Carvello <devel@baptiste-carvello.net> wrote:

> 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.

wait a minute, if I take for exemple the pytango package which contain an extension.
the python module is called PyTango and it call the _PyTango extension created using boost_python.

the path of all this is like


can you provide the organisation of the module you want to achieve for cctbx.

I do not understand for now the need of a .pth file.


> 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.

which python path are you talking about ?

> I just updated the wiki for reference.


1) for the __futur__ problem, you should ask to the debian-python
mailing list, they have much more experience than me about this.

2) to me it is mendatory to run the test during the build, for QA it is
a must. It is also interesting to allow users to run test on their own machine.

test are per module or is there a cctbx testsuite ? 



GPG public key 4096R/4696E015 2011-02-14
    fingerprint = E92E 7E6E 9E9D A6B1 AA31  39DC 5632 906F 4696 E015
uid  Picca Frédéric-Emmanuel <picca@synchrotron-soleil.fr>

GPG public key 1024D/A59B1171 2009-08-11
    fingerprint = 1688 A3D6 F0BD E4DF 2E6B  06AA B6A9 BA6A A59B 1171
uid  Picca Frédéric-Emmanuel <picca@debian.org>

Reply to: