Actually I use the first model with a simple SConscript to build executables. it is simple, although I try to keep my IMP version updated.
On Mon, Feb 16, 2009 at 1:15 PM, Daniel Russel drussel@gmail.com wrote: > I think we need to put some thought towards what ways of using IMP we want > to support. As I see it, there are two usage models to support: > 1) The user installs IMP in some standard location and uses it like any > other library. This is supported by the current scripts, if not heavily > tested (I don't think anyone currently uses it this way). Such usage is > great if you only have one version of IMP that you use, are not frequently > changing IMP, and only use python or use your own build system. > > 2) The user adds a module to IMP (but does not check it in to IMP svn) and > uses the IMP build system and imppy.sh to run things. Such usage has the > advantage that you don't have to mess with the build system (so novices > don't have to be shown much), you don't have to set your PYTHONPATH, making > changes to IMP is easy an quick, it is easy to keep IMP up to the current > svn head, and should you decide to contribute your code back to IMP, not > much has to be done. > > Currently this model is a bit messy though since you have to modify > modules/SConscript (and avoid accidentally checking in the modified file), > and, if you want to use svn nicely, modify your local svn state for modules > (to add a your module as an svn:extern). This process could be made nicer in > a couple of ways: > - move all the Scons code related to each module into the module directory > - add an external_modules directory which has a glob-based SConscript (which > doesn't need changing), but is otherwise treated similarly to the modules > directory and which can't easily be changed (other than the SConscript > file). > > Thoughts? Other usage models? Ways of making these easier? > > > I think Keren uses IMP by calling imppy.sh from an external project. I would > like to discourage this model as it doesn't give much benefit over > installing IMP, makes it harder to control what version of IMP you use > (since you can't easily check out IMP, and then not use it), and makes the > external library very dependent on details of the (necessarily) messy > imppy.sh. For example, imp using modeller through the modpy.sh script has > caused horrible and tricky to debug problems for each of use at various > points. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >