On Wed, Dec 21, 2016 at 12:29 PM, David Case <david.case.rutgers.edu> wrote:
>> I think, 'configure' needs to 1) check that the
>> current python installation will work, 2) if it won't work, tell me
>> exactly why, and what I might do to make my python install
>> Amber-compatible (what packages etc), and 3) if certain python
>> components are going to be skipped and others not, tell me up-front
>> which ones.
>
> In the past, this seemed like a pretty daunting task to do well. I
> think it would involve make using of the users PYTHONPATH as well as
> their PATH. Then it's easy if all the tests of the user's python work,
> but handling the case where some work and some don't seems hard. And
> trying to provide advice to users on how they can install missing items
> is probably impossible--do we have them use pip, conda, apt-get, manual
> download, something else? Plus, we risk having users change their system
> python in ways that break other programs.
But I think it is important that these tests happen at 'configure'
time, and it doesn't seem to me to be that difficult (but maybe I'm
underestimating the difficulty as a python n00b). In my mind it can be
done just like how we test compilers now: generate a small bit of code
that makes use of whatever feature is required and make sure it
compiles/runs. For example, pytraj (and others) requires numpy. So at
configure time generate some python script that imports numpy and
perhaps does something simple with it and then try to run it. If it
runs then congrats, your python works, otherwise exit with a message
that states what failed (numpy), that it's required, and that you can
either use the internal miniconda download or fix your numpy. We don't
have to recommend how it gets fixed - either the user can do it or
take the 'miniconda' route. Hopefully the program that fails during
configure does so in a way that makes it obvious what's wrong (perhaps
after some googling of the error message)...
> Option C: try to write (and support going forward!) a configure test that will
> figure out exactly which python components are likely to fail.
This is the correct option in my opinion and is what 'configure'
scripts are "supposed" to do (in general).
>> Having a built-in miniconda is great, unless you need to have several
>> versions of Amber installed on the same system (for e.g. different
>> compilers/parallel libraries), and then it can become cumbersome.
>
> How cumbersome is cumbersome? What's the downside of asking Amber developers
> to use the --with-python flag?
I'll have to test '--with-python', but if it works there is not much
of a downside that I can see other than that Amber installation is now
the "python keystone", so I'd better not ever move it or I will break
every Amber install based on it (and it's another configure flag that
has to be specified each time).
Somewhat related - should 'configure' be calling 'conda update' for miniconda?
Bottom line is that I feel very strongly that 'configure' should check
if the currently available python will be enough for Amber since that
is what configure tries to do for every other installation component.
The miniconda is a nice option, but I feel like the choices shouldn't
be "miniconda or nothin'".
> [Next thing we know, people are going to want to be able to specify a build
> directory, separate from the sources.....]
I still want this :-). For separate installs the size can really add
up, more because the Amber 16 source tree weighs in at 2.3 GB - the
miniconda install adds 635 MB to that (sizable but not egregious).
-Dan
--
-------------------------
Daniel R. Roe
Laboratory of Computational Biology
National Institutes of Health, NHLBI
5635 Fishers Ln, Rm T900
Rockville MD, 20852
https://www.lobos.nih.gov/lcb
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 21 2016 - 12:00:03 PST
