OK, then I'll work on moving the restraints and stuff I maintain into my svn repository. I'll put the general purpose restraints in IMP::dsr (unless someone has a better name to propose) and the npc dynamics ones into IMP::npc_dynamics.
How do the python library names work for sub-libraries? i.e. IMP is _IMP.so so what is IMP.em? Does it just go in a dir called IMP in your python path?
So then we will have a kernel which is actually a kernel (plus a couple random restraints and things :-)
Ben Webb wrote: > 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 >