[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[IMP-dev] Ways of using IMP



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.