Re: [IMP-dev] One final attempt to stir discussion before I give up on IMP svn

[Ben Webb <>]

Friedrich Foerster wrote:
> what is all the fuzz about? i thought ben already proposed a neat  
> solution in that not everything needs to be in the kernel. anyway, imp  
> was meant to be modular, i thought. so whatever does not need to be in  
> the kernel should not be there and in a different module instead. in  
> that module everybody can mess around as he wishes, at least to some  
> extent.

Indeed. This is exactly what I proposed, but perhaps more succinctly 
put. All sorts of things rely on the kernel interfaces being stable, and 
the lab culture is to use current SVN for everything, so code changes 
there should go through code review, which thus far means me. The kernel 
was always envisioned to be compact; almost everything else belongs in a 
module. (If nothing else, this prevents the SWIG wrappers from becoming 
monstrous.) This could be remotely hosted (e.g. a lab outside of UCSF, 
or in a different SVN repository in the lab, as is currently done for 
Assembler) or it could be in IMP SVN (as is done for domino and impEM). 
Modules need not be subject to the same scrutiny - for example, Keren 
has write access to the domino and impEM modules. She does not need to 
send me patches, chat on the mailing list, undergo code review, etc. - 
although typically she is responsible and sends any changes by me first 
for review. Each module has an owner (Keren in this case) who works with 
me to set whatever policies they think are sensible. For impEM, so far 
this has meant I continue to review changes, since Keren was happy with 
that. For Assembler, Keren and Frido have essentially equal access. One 
could also envision a restrainer module owned by Jeremy, or an 
npc_dynamics module owned by Daniel, for example.

For experimental stuff that doesn't neatly fit into an existing module, 
I could certainly create an 'unstable' module if there's interest. 
Essentially everybody would have write access to this module. Code 
review and test cases are still strongly recommended, of course, but 
failures of the test cases would not result in the nightly builds 
failing. So users would use the 'unstable' module at their own risk.

As per Keren's suggestion, stuff from 'unstable' that users start to 
rely on can be moved to a more specialized module, or to the kernel 
after code review. (One could even imagine having both an unstable and a 
stable form of a given feature, although I'd like to minimize that if 
possible.)

To avoid confusion and namespace clashes, I propose that a module 'foo' 
has its C++ code live in the IMP::foo namespace, C++ headers in IMP/foo/ 
(or IMP/foo.h if the module provides a convenience 'everything' header), 
and Python classes in the IMP.foo module. So the existing IMPEM Python 
module would become IMP.em and move from the IMP namespace to IMP::em. 
This also fits in nicely with existing Python-only modules such as 
IMP.modeller_intf (ideally would be IMP.modeller, but until we can 
require Python 3.0 or later, we're stuck with relative imports). And if 
users wonder why their code keeps breaking, it should be obvious from 
looking at either C++ or Python code whether they're using 'unstable'.

	Ben
--
                      http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
	- Sir Arthur Conan Doyle