[cctbxbb] Debian Package

[Nathaniel Echols]

On Thu, Aug 9, 2012 at 10:27 AM, Baptiste Carvello
<devel at baptiste-carvello.net> wrote:
> 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