[cctbxbb] Debian Package

[Luc Bourhis]

Hi Baptiste,

> Le 09/08/2012 03:35, Luc Bourhis a écrit :
>> Radostan Riedel wrote:
>>> OK to make that clear a little bit. A few patches are really only for
>>> packaging
>>> they can't and shouldn't go back upstream.
> 
> 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.

Actually we are not opposed to move as many patches as possible to our trunk, providing that they are introduced in as incremental a manner as possible if they affect existing code, and if the authors of the patch quickly react to any breakage of our nightly tests so that after a couple of days they pass with flying colours. This is basically what we ask of all of the cctbx developers. 

Now fair enough, if you study the cctbx repository log, you will see that some people, especially me, pushed as many as 50 commits in one go. But that's because I used git to mirror my work on a representative sample of the machines used for the nightly tests, running a full build and a full test on each chosen machine, fixing problems along, and sending the patch bomb only when all problems were ironed out. Even then, it happened that some bugs surfaced on very old or very new Linux distros I had not tested.

Either way, it is almost unheard of that the cctbx trunk was broken for more than a few days in a row and we would like to keep it that way. I am sure Nat would be more than happy to give you access to our test machines so that you can do this sort of testing. The alternative would be that all patches go through one of us. I could volunteer to do that.

>> we wanted the cctbx to always be
>> run with -Qnew and we actually had to fix the code in quite a few places
>> to make all tests pass with -Qnew. Having those Python dispatchers in
>> the first place, the least intrusive change was definitively to add
>> -Qnew. The alternative, adding "from __future__ import division" to
>> every single Python module did not appeal to us. Thus that build_py
>> class is definitively necessary.
> 
> 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:

Have you run all the tests without -Qnew to affirm that? I mean just search for the regex \b\d(?!\.)/\d(?!\.) for example and you will see how many potential breakages the omission of -Qnew would produce. 

> * either because they already have the __future__ line, probably because
> it was already there, and has not been actively stripped,

You are correct about that: some of us had got into the habit of systematically adding "from __future__ import division" before the move to -Qnew.

> * 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.

the x/2. pattern was the alternative to adding "from __future__ import division" used by some developers indeed whereas most of the x//2 were added during the move to -Qnew iirc.

> If we think that such a style will stay the norm in the future, we don't
> need any workaround.

Believe me, we need __future__ division.

> Sure. I'll take a few days off starting friday, but I'll be back in the
> middle of next week.

Same here.

Best wishes,

Luc