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 <> 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
>
> https://salilab.org/mailman/listinfo/imp-dev
>