> On Feb 22, 2015, at 5:17 PM, Scott Brozell <sbrozell.rci.rutgers.edu> wrote:
>
> Hi,
>
> On Sun, Feb 22, 2015 at 12:45:05AM -0500, Jason Swails wrote:
>>> On Feb 21, 2015, at 10:52 AM, David A Case <case.biomaps.rutgers.edu> wrote:
>>> On Sat, Feb 21, 2015, Gerald Monard wrote:
>>>> No odd numbers anymore. It also leaves some
>>>> time (until the '16 release) to re-factor the directories and decide if
>>>> we drop the AmberTools naming.
>>>
>>> A couple of points along this thread:
>>>
>>> 1. We can't merge the AmberTools and Amber source trees together. The
>>> split between the AmberTools stuff and the pmemd stuff is there because
>>> they fall under different licenses. Intermingling the trees would just
>>> confuse that issue.
>
> This does not make sense. pmemd has its own source directory and license
> file as do some other programs (and as ~every program once did before
> Dave rearranged things years ago):
> src/pmemd/src/copyright.i
> AmberTools/src/cpptraj/LICENSE
> AmberTools/src/reduce/LICENSE
> Please provide a syllogism that explains the split.
See below.
>> I agree. This is probably one of the more important distinctions we make. For people that just want to *use* Amber, it doesn't *really* matter where the source code lives... all the programs get dumped to the same place, anyway. The people that actually care about the source code directory structure are probably more likely to try modifying it and therefore probably care more about licensing issues.
>
> Yes, this matters to people that actually care about the source code
> directory structure - namely, developers.
> I have tried and never understood this AmberTools split.
> Others also do not understand it.
I was not a proponent of this scheme when it was proposed at my first Amber meeting -- I had proposed a completely different scheme (rather similar to Ross’s, IIRC). However, it is exceedingly easy to understand. “Everything in AmberTools is [1] FOSS covered under GPL/LGPL, or something compatible; nothing in src/ permits redistribution”. The debate here really centers on whether this mission statement justifies the split. In your opinion, clearly not. In my opinion, meh; I could go either way... slightly more toward the side of being justified.
It also has another *functional* benefit (to *me*, it is much more important) -- *all* source code provided for free by AmberTools resides in $AMBERHOME/AmberTools. Likewise, *all* paid source code resides in $AMBERHOME/src. This is intimately important to update_amber and keeping the updates as simple as possible (“simple” being a relative term here):
- Simple to create for us
- Simple to disseminate for us
- Simple for users to access, find out about, and apply
- Simple for update_amber to provide rigorous error/sanity checking to limit (hopefully eliminate) issues that could cause widespread confusion and frustration for everybody that would be difficult for us to recover from.
The current directory split was VERY convenient when I designed update_amber, and it lies at the very center of some of its (IMO, critically important) sanity checking and bookkeeping functionality. If that scheme was not in place, I could have worked around it with some added complexity. But the simpler I was able to keep things, the more confidence I had in its robustness. The move of sander to AmberTools introduced some headaches, since the delineation b/w Amber and AmberTools changed from $AMBERHOME/AmberTools vs. $AMBERHOME/{src,test} to $AMBERHOME/{AmberTools,test} vs. $AMBERHOME/{src,test/cuda}. But that change was small enough so was to (fortunately) not introduce any additional complexity to update_amber.
And best of all for me, this scheme is *extensible*. If more components are added to either the paid or free parts, dumping it in AmberTools or src makes it work within the update_amber system *for free*.
I could work around a change that will unify the source trees. However, depending on how it’s done, it could threaten the simplicity of how we create, disseminate, *and* implement updates with regards to rigorously correct bookkeeping or it would seriously compromise the currently future-proof sanity checking built into update_amber right now. The best thing would be to have separate *containers* so it’s simple to tell where each component lives... but that’s exactly what we have now.
> Consequently, the split continues to appear arbitrary, and all recent
> explanations attempts either do not provide a sound argument or are
> 'well what we have now isnt so broken’.
None of the alternate proposals that I’ve heard here will have *any* impact at all on user experience (i.e., we still plan on doing “./configure; make install” to dump everything to $AMBERHOME/bin) so I fail to see any functional justification for why a merger needs to happen or stuff needs to be shuffled around.
I may not have been a proponent of the original proposal, but I certainly have a vested interest in keeping the paid/unpaid segregation intact *and* simple unless somebody else plans to take over maintaining update_amber. And update_amber walks a fine line between making users’ (and update creator’s) lives *much* easier or making their lives more difficult than before by not being resistant to malformed updates among any other problems. There was a *lot* of design, testing, anticipation of potential problems, and trying to build in the ability to handle unanticipated problems that went into designing and writing update_amber; it had to be very robust, yet as flexible as possible in order to meet its stated goal, which I think it has. Another thing I tried to consider in the design was future-proofing it as much as possible so that its maintenance could be picked up by someone else as easily as possible if/when I moved on from Amber.
So rather than posing discussions on directory layout within the tarball from the status quo 10 years ago and not liking the split in the first place, let’s start from the present where the current split *does* exist and serves a functional purpose. Unifying the source directories is a fundamental change to the functionally useful separation we have now, and I think making that change should be justified by more pros than cons.
Of course if pmemd is released for free, everything becomes “Amber” again, and I’ll happily retract my whole defense of $AMBERHOME/AmberTools/.
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sun Feb 22 2015 - 18:30:03 PST
