> Somewhat related - should 'configure' be calling 'conda update' for
miniconda?
yeah, it should. I will update it.
> it doesn't seem to me to be that difficult (but maybe I'm
underestimating the difficulty as a python n00b)
actually difficult but doable. For example, in the past, pytraj and
libcpptraj were compiled fine but got segmentation fault at run time on Mac
OS
(since pytraj uses stdc++ from miniconda while libcpptraj use stdc++ from
clang).
We fixed that but it took time.
But in general, I agree with you that configure should do better job in
checking.
The hidden agenda in supporting Miniconda is that it's very easy to install
Jupyter notebook (now) or Jupyterlab (in the future) with
conda. The notebook is very useful for interactive computing and
visualizing.
This is one of the ways to start distributing AmberTools in windows too
(where noob users just need to open the notebook rather than playing
around with command line CMD or msys2).
Per build folder, I am +1 for this. We should probably add --prefix flag.
Hai
On Wed, Dec 21, 2016 at 2:50 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 21 2016 - 12:30:02 PST
