Re: cctbx debian package
On Wed, 18. Jul 16:45, Baptiste Carvello wrote:
> Hi all,
> I had overlooked this pycbf.py file, and thought only .so extensions
> existed in lib. Now, it looks like this file is automatically generated,
> so it should definitely not be included in the patch. I'll see how to
> move it with distutils, I don't think it will be difficult.
Let's try to look if we can get it into cbflib package like Fred suggested.
> Radi, a question for you about this: moving boost_adaptbx/boost to boost
> means it can be imported with "import boost", but no more with "from
> boost_adaptbx import boost". Unless I'm mistaken, the upstream packaging
> allows both. Should we not do the same (a .pth file allows that)?
I think the way it build now it just copies boost into top directory so both
could work but I might have overlooked something.
> Further questions:
> * I had understood that we would create several debian packages for the
> python interface. This is the reason why I created several setup-xx.py
> scripts. Do you think we should rather build a single python-cctbx
> package, or is it just a temporary fix.
I think it's easier to use one setup.py and split the files up with
package.install files. You can look into python-cctbx.install to see how it
works. dh_install takes care of the right place.
> * your setup.py uses "extra_path = 'cctbx'". Will this not force users
> to write (for example) "import cctbx.cctbx.sgtbx" instead of "import
> cctbx.sgtbx"? Or is there something I overlooked?
extra_path just creates a directory cctbx and adds a cctbx.pth file. This way we
keep all modules in on path. It was just cosmetics but we can remove it.
> What I'll try to do until the end of the week:
> * fix the pycbf.py and stdlib.py problems
> * move the .so extensions back to the root of the package, so that they
> are directly importable (needed for scitbx.array_family.flex)
Have you checked out my commit? I changed a little bit your scripts and I think
this should already work. If you don't like my changes then tell me or fix it.
> * use distutils to add a "from __future__ import division" line to the
> files that lack it.
Nice! Can you also think of a way to get a nice clean target. I guess the
build2.7 directories are not cleaned.
> I'll tell you when this is done, so you can update your patch.
Or you can push your changes in right away into the git so you be