Next version of the proposal: - mudulename/bin becomes internal, undocumented, utility executables (eg the benchmarks). They will not get installed in build/bin or installed at all with imp. protein_ligand_score gets moved to
- applications which has executables that users are supposed to see (we will add facility to document the applications in a similar manner to how modules are currently documented). The code is not expected to be read by random users and the applications will get build into build/bin and installed in bin.
- a new directory, biological_systems will be added. In there will be scripts with data that have been published in separate papers about the biological system in question, The scripts should be written so as to be readable and modifiable by others.
Comments?
On Oct 30, 2010, at 11:36 AM, Keren Lasker wrote:
> i am not completely sure how to best divide application module/bin, > module/example. > To my understanding applications was suppose to be a complete protocol > for a specific complex (such as Nup84). > I added simple scripts like resampling / simulating density maps to > applications/em, but they should probably move to em/bin. > the problems with the current system are: > 1. when someone opens IMP and looks for where to start, it would be > good to direct to clear and simple tutorials. This is not the case now. > 2. each application in application/module and tutorials uses more > than one module, so users that want to look for application of modeling > +em should go to atom / modeller / em / 2dem / multifit - its not > clear. > > My suggestion is: > module/example - simple examples of specific code as now > module/bin - utilities to run functionalities of the module that > produce meaningful output (basically what that is in applications now > and javi's 2dem/bin is a great example) > applications/method - subdirectory for each complete method (paper) + > tutorial if written > applications/systems - subdirectory for each biological system (such > as Nup84) > > I do not have strong preferences either way so what ever decided is ok > with me, as long as we will decide on a clear definition for what > should go where. > > > On Oct 30, 2010, at 11:13 AM, Dina Schneidman wrote: > >> we also have applications... >> >> On Sat, Oct 30, 2010 at 10:47 AM, Keren Lasker kerenl@salilab.org >> wrote: >>> because they are a set of scripts that should be run together. >>> so it more of a protocol then an example of a specific functionality. >>> On Oct 30, 2010, at 12:49 AM, Daniel Russel wrote: >>> >>>> How are tutorials different from examples? >>>> >>>> On Oct 29, 2010, at 11:15 PM, Keren Lasker wrote: >>>> >>>>> >>>>> We have few sets of tutorial scripts that are currently scattered >>>>> in >>>>> various modules within imp and outside of imp. >>>>> I think it would make sense to have a module named tutorials and >>>>> then >>>>> subdirectories for the different tutorials. For example, our recent >>>>> book chapter on assembly modeling by comparative modeling and em >>>>> can >>>>> go there. >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> _______________________________________________ >> 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