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
/usr/lib/python2.6/dist-packages/PyTango/_PyTango.so
/usr/lib/python2.7/dist-packages/PyTango/_PyTango.so
/usr/lib/python2.6/dist-packages/PyTango/__init__.py
/usr/lib/python2.7/dist-packages/PyTango/__init__.py
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.
thanks.
> 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.
thanks
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 ?
Cheers
Frédéric
--
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: