On Thu, Aug 9, 2012 at 10:27 AM, Baptiste Carvello
Well, they shouldn't go into the packages. But if they end up beeing shared with other distros in the future, it could make sense to host them in a branch of your source repository. Time will tell.
Personally, I am very reluctant to introduce branching if there's some way to avoid it.
Regarding installation by hand: the setup.py file could a priori also be used by end-users to install cctbx to the system python library. I didn't discuss this possibility because such a system install doesn't seem to be a supported way to install cctbx.
It isn't, but it would be great if this became possible at some point in the future. We (Berkeley folks) haven't invested any effort towards this goal in the past because it wouldn't make it any easier for us to distribute Phenix, which is a much larger and messier infrastructure, and since we still depend on the current, non-standard CCTBX build system for those other modules, we will never be able to get rid of it entirely. However, I suspect the current system discourages adoption of CCTBX by other potential users, so an alternative would be very welcome.
The thing is, right now, most modules in cctbx don't need an additional __future__ line at all. They run equally well with or without "-Qnew", for one of 2 reasons:
* either because they already have the __future__ line, probably because it was already there, and has not been actively stripped,
* or because int division is not used at all. The most common style, from the little I could see, seems to be using explicit constructs in all cases, for example "x//2" (explicit integer division) or "x/2." (explicit floating-point division). This style nicely sidesteps the problem.
If we think that such a style will stay the norm in the future, we don't need any workaround.
I actually think introducing -Qnew was a mistake, because there are third-party modules which we rely on (mostly in Phenix, although some stuff has trickled into CCTBX) which simply break when true division is forced. The Python Imaging Library is the worst offender, and unfortunately it looks like it's no longer maintained. I definitely agree that it would be better if everyone continues to use the explicit division styles instead of relying on the Python interpreter's default behavior, and if there is code in CCTBX where this isn't happening, it is probably worth changing. Unfortunately, once again we're constrained by the rest of Phenix, which is less easily fixed, so -Qnew needs to stay in the default dispatchers for now. -Nat