Look at this from the bright side: at least it's not docker or, worse,
a virtual machine :-) I agree that those virtualisation attempts seem
to go out of hands (quite) a bit but when you have to maintain Python
code, dependent on 3rd party libraries especially, you quickly learn why
you want to do this. On MacOSX this is just a nightmare and packaging
your own Python distribution (or go miniconda or similar) seems to be
the only sensible way to go. I learned that the hard way... And don't
get me started on UCS2 vs UCS4 being a compile-time option in 2.7. I
had to tell 3(!) sysadmins that they really ought to look into how
(Linux) distributors build their stuff (hint: Linux distributions do
not use the default of UCS2).
On Thu, 28 Jan 2016 16:42:10 +0100
Josh Berryman <the.real.josh.berryman.gmail.com> wrote:
> 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.
>
> Josh
>
>
>
> On 28 January 2016 at 16:32, Ross Walker <ross.rosswalker.co.uk>
> 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
> > 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 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 |
> > | http://www.rosswalker.co.uk | http://www.wmd-lab.org |
> > | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> > ---------------------------------------------------------
> >
> > 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.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Jan 28 2016 - 08:30:03 PST
