On Fri, Dec 23, 2016 at 8:44 AM, David Case <david.case.rutgers.edu> wrote:
> On Thu, Dec 22, 2016, Jason Swails wrote:
> >
> > 1. I think we should support users having anaconda or Miniconda on their
> > system and use that installation if available. This can be as simple as
> > just checking to see if there is a "conda" executable in the same
> directory
> > where `which python` is located.
>
> I'm OK with this if people think it is safe enough: existing miniconda
> installations probably don't have all the packages Amber needs, so this
> seems
> likely to cause errors downstream (absent a true compatibility check inside
> confiure2.)
>
It's definitely safe enough (after all, it's my experience with those
packages that gave me the idea to use miniconda in the first place :)). My
logic here is that anybody that has Anaconda or Miniconda is actively using
Python as part of their standard toolkit, and we should do what we can to
work as part of it. They also presumably know how to use it enough to
install the packages we need (which is basically the bare minimum of what
anybody using Python seriously will need).
Another thing we can (should?) do, which is standard in many Python
packages, is provide a requirements.txt file. Then we can offer the users
a helpful command to install all prerequisites:
# conda-based Python installations:
conda install --yes --file requirements.txt
# Non-conda-based Python installations
pip install -r requirements.txt
What about instructions suggesting that people with existing
> anaconda/miniconda installations consider using the --with-python flag?
> (i.e. instead of using an existing anaconda/miniconda by default?)
>
If we're going to prompt users on whether they want to install Python or
not, why not just change that prompt for users that have conda to "do you
want to use your existing miniconda/anaconda installation or have Amber
download its own?" -- no need to bring extra flags into this if we don't
have to :).
The main reason I suggested making it default was because *not* doing that
would end up raising that question (or requiring the flag) every time
someone decided to run configure (which means that those users can't really
copy-and-paste canned installation instructions or necessarily transfer
build scripts between machines where their Pythons may be in different
locations).
> > But strangely enough, the bundled FFTW3 version
> > was actually more integrated into the standard build scripts than NetCDF
> > was, and therefore harder to extricate.
>
> This is worth trying to fix. Probably a better use of people's time than
> the
> effort to get everything running on Windows 7/8.
>
+1 for this.
Thanks,
Jason
--
Jason M. Swails
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Dec 23 2016 - 07:00:03 PST
