On Wed, Dec 21, 2016, Dan Roe wrote:
> When I say "no", I get this message:
>
> ```
> OK. I will try to use /mnt/local/droe/anaconda2/bin/python, but not
> all Python components in Amber will work correctly...
>
> I think a better solution for situations like this in the future will
> be to have 'configure' check if downloading Amber's miniconda is
> actually needed to make programs run.
> 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.
So:
Option A (my choice): if the user declines the miniconda install,
configure exits with a clear message that it needs to be re-run with
either the --with-python or the --skip-python flag. These seem like
understandable options; users like Dan can just get used to adding
--with-python to their configure workflow.
Option B: more like the present: use the python in the
PATH, and change the above message to "I will try to use
/mnt/local/droe/anaconda2/bin/python, but some python components in Amber
may not work correctly."
Option C: try to write (and support going forward!) a configure test that will
figure out exactly which python components are likely to fail.
Option D: use option "A" for now, and wait to see who steps forward to
implement option "C".
> 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?
[Next thing we know, people are going to want to be able to specify a build
directory, separate from the sources.....]
....dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 21 2016 - 09:30:03 PST
