On Thu, Jan 28, 2016 at 8:59 AM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
> What is going on here? Should we downloading all this stuff and installing
> it? It seems like this could be a serious security concern for some people
> and also extremely fragile.
>
We are trying out some ideas for providing a reliable Python environment
for an improved user experience. The main goals here are to provide an
environment where our Python scripts can run in a version-compatible Python
*and* so that we can expose our Python functionality that others would like
to hook into more easily and reliably (for instance, through pysander,
pytraj, etc.). This is already being done through some collaborations,
like improving xtal refinement through Phenix.
This workflow is currently utilized by many automated services and is
fairly robust. It is also secure -- Continuum's business depends on it.
It also polutes the git tree and a make clean / make dist clean does not
> clear this up.
>
Everything it does is put inside $AMBERHOME/miniconda. This is hardly
polluting. We can have make clean/make distclean clear this stuff out
quite easily ("make clean" should definitely not touch this, but there's an
argument to be made that distclean should). I can expand on why I *didn't*
have distclean remove this if you want my explanation.
In my opinion we really really really should not be depending on tons of
> external libraries and the configure script in AMBER should definitely NOT
> be connecting to any external sites EXCEPT ambermd.org.
>
You're certainly entitled to your opinion, but mine is that this stance is
rather arbitrarily purist. The reason I say it's arbitrary is because it
would be easy to simply host those files on ambermd.org -- but why not take
advantage of their (i.e., Continuum's) better web infrastructure (more
reliable web service, more bandwidth, faster connection to more areas, ...
etc.)?
It also should not be doing this for a configure that does not involve an
> AMBERTools build.
>
I've fixed this. I've also improved the CUDA configure so it doesn't try
to configure (an unused) FFTW-3.
A couple other notes -- it seems you're using an outdated version of the
tree. configure no longer goes off and does this on its own. It's smarter
about figuring out when it should do this and then asking for permission.
It's also circumvented entirely by specifying a python to use with Amber.
For instance, if you do `./configure --with-python /usr/bin/python gnu`, it
will simply use /usr/bin/python and never attempt to build its own.
Feedback is appreciated, and is how we will hopefully provide the best and
easiest experience for both users and developers.
I will also fix this to not be a fatal issue when connectivity is a problem.
Thanks,
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 Thu Jan 28 2016 - 07:00:03 PST
