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.
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 >
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. ... > 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.
(1) is pretty much the standard way "normal" packages work, so I think should be the only one we support. We could possibly provide a simple set of SConscripts for those wanting to link programs or other modules against IMP.
> I think Keren uses IMP by calling imppy.sh from an external project. I > would like to discourage this model
I agree.
Ben
> > >> I think Keren uses IMP by calling imppy.sh from an external >> project. I >> would like to discourage this model
I'll have to discuss it with Frido, as what you refer to here is the assembler code developed by Frido and myself. but - quick question: can one have two svns, the root to svn A is child of svn B ( in the filesystem directories tree), and the children/leaves of A are always in svn A ?
On Feb 18, 2009, at 8:59 AM, Keren Lasker kerenl@salilab.org wrote:
> >> >> >>> I think Keren uses IMP by calling imppy.sh from an external >>> project. I >>> would like to discourage this model > > I'll have to discuss it with Frido, as what you refer to here is the > assembler code developed by Frido and myself. > but - quick question: > can one have two svns, the root to svn A is child of svn B ( in the > filesystem directories tree), and the children/leaves of A are > always in svn A ?
I don't understand. You can always stick a folder in an svn copy that happens to belong to another repository.
> _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
yes - this is what i thought - just wanted to make sure again , that we will not run into cvs kind of problems On Feb 18, 2009, at 9:22 AM, Daniel Russel wrote:
> On Feb 18, 2009, at 8:59 AM, Keren Lasker kerenl@salilab.org wrote: > >> >>> >>> >>>> I think Keren uses IMP by calling imppy.sh from an external >>>> project. I >>>> would like to discourage this model >> >> I'll have to discuss it with Frido, as what you refer to here is >> the assembler code developed by Frido and myself. >> but - quick question: >> can one have two svns, the root to svn A is child of svn B ( in >> the filesystem directories tree), and the children/leaves of A are >> always in svn A ? > > I don't understand. You can always stick a folder in an svn copy > that happens to belong to another repository. > > >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
Keren Lasker wrote: >>> I think Keren uses IMP by calling imppy.sh from an external project. I >>> would like to discourage this model > I'll have to discuss it with Frido, as what you refer to here is the > assembler code developed by Frido and myself.
Isn't the change to Assembler as simple as running "scons prefix=/foo install" in IMP and then modifying your Assembler run script to set PYTHONPATH and/or LD_LIBRARY_PATH to include /foo/lib ?
> can one have two svns, the root to svn A is child of svn B ( in the > filesystem directories tree), and the children/leaves of A are always > in svn A ?
Maybe SVN externals could be used to get what you want? http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.advanced.externals
Ben
On Feb 18, 2009, at 7:54 AM, Ben Webb wrote:
> 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. > ... >> 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. > > (1) is pretty much the standard way "normal" packages work, so I think > should be the only one we support. We could possibly provide a simple > set of SConscripts for those wanting to link programs or other modules > against IMP. My reasons for suggesting have 2 around are: - it is nice to be able to use IMP in place when developing since you typically have multiple copies of the library that you are using (I would strongly encourage people who are checking things in to have a copy which is the current svn version so you can test your checkins easily for missed files and stuff) - it is a pain to have to propagate changes back from installed headers to SVN ones (the debugger for external programs will take you to installed headers and it is easy to get confused about which version of the headers you are editing). - not everyone around seems to be comfortable setting up a build system, so it is nice to have a canned solution for them. - we already have all the necessary hacks in place since that is how you set things up initially :-)
participants (4)
-
Ben Webb -
Daniel Russel -
Dina Schneidman -
Keren Lasker