Re: cctbx debian package
On Mon, 16 Jul 2012 11:41:13 +0200
Radostan Riedel <raybuntu@googlemail.com> wrote:
> On Mon, 16. Jul 09:41, Baptiste Carvello wrote:
> > OK, the problem was that the upstream build system insists on running
> > with the same python version that was configured. So when just calling
> > the system scons command, which uses the system default python, I can't
> > build both versions.
> >
> > But I just thought of an easy way to work around this: I'll add
> > /usr/lib/scons to the PYTHONPATH and directly call SCons.Script.main()
> > with the python version I need.
> I just did a:
> python$* /usr/bin/scons
So we just need to configure with the right python$* version and that's all.
> > 1) contrary to Radi's setup.py, mine installs packages directly into the
> > main python path. That means you would import scitbx with "import
> > scitbx", not "import cctbx.scitbx". I think it is better because both
> > the upstream python files and user scripts use the first idiom. However,
> > I was hesitating about boost_adaptbx: is it acceptable to install it as
> > just "boost" in the main namespace?
> OK I thought about that too last year but I didn't wanned to break upstreams
> logic. Also we need to be aware that other projects use that logic too!
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 :).
> > 2) upstream installs the .so extensions into the main python path, but
> > almost all of them are only imported from one place inside the packages.
> > So I moved them there. There is however one exception:
> > scitbx_array_family_flex_ext.so gets imported from several places, so I
> > need to either keep it global, or write an import stub.
> I really think if we want to move anything around we need to talk with upstream
> and make sure not to break anything for other projects that depend on cctbx.
> What did you do about that problem that they are importing PYTHONPATH for a
> subdir in boost_adaptbx. I just moved that "boost" dir up but this means that we
> have a directory that can be mistaken as pure boost bindings. I mean we could
> have a naming issue here too.
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.
Did the graph module represent exactly what is expected ?
>
> But all in all you made some real great progress!
Yes to both of you :)
Cheers
Fred
--
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: