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 acknowledged ;). kind regards Radi -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
