Re: cctbx debian package
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
It also works. Check out my latest commit.
> Nothing really severe, just 2 small things:
>
> 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!
>
> 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.
But all in all you made some real great progress!
regards
Radi
Reply to: