...
The 3 schemes we consider are enumerated here:
* 2-Package (Fermitools + Extras)
* 3-Package (Base + Core + Extras)
* N-Package (Fermitools-meta)
2-Package (Fermitools
...
& Fermitools-extras)
This scheme would see a central block of the main Fermitools retained, while a group of less commonly used elements of the tools pared split off into a package named ''Fermitools-extras''.
''Fermitools-extras'' depends upon the now-smaller The core "Fermitools" package for central libraries like would hold all base libraries and dependencies ''tip'', ''likelihood'', ''irfs''... etc. The extra and all important end-point utilities such as gtbin, gtselect, and the python interface modules such as gt_app, pyLikelihood etc. The "Fermitools-extras" package should contain less commonly used tools like pgwave, gtorbsim and gtobssim, along with their external dependencies, like ROOT. Ideally ROOT would only be a dependency of ''Fermitools-extras'', and would no longer be a dependency of "Fermitools". The now smaller "Fermitools" package would be a dependency of the "Fermitools-extras" package.
``[Fermitools] ==> [Fermitools-extras]``
...
This scheme builds upon the 2 package scheme by further partitioning off a set of "Base" modules from the core fermitoolsFermitools. This base package would contain all the modules that are rarely updated dependencies of most other fermitools: ''tip'', ''ST_APP'', ''facilities'', etc. would all be in this ''Fermitools-base'' package. Libraries under active development (Likelihood) along with all user applications (gtbin, modeleditor) would remain in the ''Fermitools'' package, which we might internally refer to as Fermitools-core.
...