[cctbxbb] Debian Package

[Baptiste Carvello]

Le 09/08/2012 19:55, Luc Bourhis a écrit :
> 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.

OK to all that. Regarding the setup.py patch specifically, if it is
considered too big, I can probably split it into more digestible pieces.

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

Well, "most" may be overstated, that was just my impression. I did not
make a full test run yet, either without -Qnew, or with my workaround.
Both of which would be very interesting for sure...

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

OK, so basically this style is a leftover from the past, not a
coordinated effort to keep the code working without "-Qnew". That
answers my interrogations.

> Believe me, we need __future__ division.

I take your word on this! Then we'll use my "build_py" code. As I said
above, I could not yet make sure all tests pass, because some tests are
not correctly installed and won't run at all. But I'll try to reach that
milestone as soon as possible.

Cheers,
Baptiste