Re: [AMBER-Developers] Latest configure script seems to want to install tons of third party dependencies?

From: Josh Berryman <>
Date: Thu, 28 Jan 2016 16:42:10 +0100

Have to throw in my 2c here, sorry, but I hate it when applications run off
and get their own python. Bloat city, having two complete python installs
(2.7 and 3) already feels like too many.


On 28 January 2016 at 16:32, Ross Walker <> wrote:

> >
> > This workflow is currently utilized by many automated services and is
> > fairly robust. It is also secure -- Continuum's business depends on it.
> >
> There is no guarantee this is secure and certainly without some kind of
> contract in place (which could be as simple as someone going and
> registering with them) it definitely does not count as secure.
> > 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.
> >
> make clean probably should not remove this but make distclean should in my
> opinion. Ultimately I'd expect make distclean to take me back to
> effectively immediately after I untarred things.
> > In my opinion we really really really should not be depending on tons of
> >> external libraries and the configure script in AMBER should definitely
> >> be connecting to any external sites EXCEPT
> >>
> >
> > 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 -- 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 is definitely not arbitrarily purist. It is perfectly reasonable and
> widely used business practice. This is connecting to something and
> downloading without the users permission. This is very bad practice (and
> possible illegal in a number of countries). We should be very careful here.
> We can't assume that an internet connection is available for installing
> AMBER and even if it is we can't be downloading something that requires us
> to rely on a third party. Yum install blah etc is fine because it uses
> repositories that users explicitly agreed to when installing the operating
> system. Note most major companies host their own repositories internally
> and require there installations to have passed internal security audits.
> This circumvents that and would raise a lot of red flags at any pharma
> company for example that uses AMBER.
> In my opinion this is dangerous and unreliable road to go down that could
> expose us to a number of potential problems, both practical and legal.
> > 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.
> I haven't updated in a few days because I am traveling with extremely
> limited internet connectivity - the other problem I ran across here when
> tethered to my phone it tried to download a ton of stuff just from me
> running ./configure. If the new version asks for permission this better -
> although I'd hope that the description of what it is going to do and what
> is involved (and what it involves the user explicitly consenting to) should
> be very clear.
> > It's also circumvented entirely by specifying a python to use with Amber.
> Can it not be the reverse? This would seem much better to me. E.g. test
> for all different combinations etc and only if it finds something that
> doesn't work does it then ask one to specify the python to use or offers to
> download miniconda? E.g. I have no idea which python's are on my machine,
> where they are etc. I expect it to just find python in the path and work.
> This is how it should be by default unless I explicitly specify otherwise.
> > 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.
> Why can't we just do 'which python' and have that be the default and then
> you can override it if you are an expert user?
> > I will also fix this to not be a fatal issue when connectivity is a
> problem.
> >
> That's a definite requirement since there are may systems where people
> install AMBER that are not freely connected to the outside world. Granted
> rarely in academia, where things tend to be loose security wise, but in a
> commercial environment this is the norm.
> All the best
> Ross
> /\
> \/
> |\oss Walker
> ---------------------------------------------------------
> | Associate Research Professor |
> | San Diego Supercomputer Center |
> | Adjunct Associate Professor |
> | Dept. of Chemistry and Biochemistry |
> | University of California San Diego |
> | NVIDIA Fellow |
> | | |
> | Tel: +1 858 822 0854 | EMail:- |
> ---------------------------------------------------------
> Note: Electronic Mail is not secure, has no guarantee of delivery, may not
> be read every day, and should not be used for urgent or sensitive issues.
> _______________________________________________
> AMBER-Developers mailing list
AMBER-Developers mailing list
Received on Thu Jan 28 2016 - 08:00:05 PST
Custom Search