Just FYI: I made some changes for configure. Please feel free to reword.
- won't install scipy to reduce size (Pengfei is ok with this). The
Miniconda size is reduced by half now.
- only install cython if we are using unreleased version (by checking
mkrelease_at file)
- better message why using Miniconda
Hai
On Thu, Dec 22, 2016 at 10:09 AM, Nhai <nhai.qn.gmail.com> wrote:
> Per --prefix stuff: i am still +1 for this and can help testing if you do
> that.
>
> We are working on binary distribution and really want to get rid of
> AMBERHOME envs. :d
>
> Hai
>
> > On Dec 22, 2016, at 9:44 AM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> >
> > On Wed, Dec 21, 2016 at 10:04 PM, David Case
> > <dacase.scarletmail.rutgers.edu> wrote:
> >>
> >>> On Wed, Dec 21, 2016, Dan Roe wrote:
> >>>
> >>>
> >>> But I think it is important that these tests happen at 'configure'
> >>> time, and it doesn't seem to me to be that difficult....
> >>
> >> It may indeed be do-able, but it is not just a matter of seeing if
> "import
> >> numpy" throws an error. The configure script would have to compile
> python
> >> extensions in the same way the real code will (which is actually several
> >> ways), and make sure they all work. And since only developers will
> decline
> >> the miniconda download, and since they can find out by trial and error
> if
> >> their system python works, writing and maintaining this functionality
> seems
> >> like a lot of work for only a small payback.
> >
> > I think that some users (maybe installs at HPC sites etc) may also
> > want to decline the miniconda download, but it does seem like python
> > detection is problematic. As long as the '--with-python' flag works I
> > think it's fine anyway. It would be nice to have configure be able to
> > test the python ecosystem but if it's too much work then I'll just put
> > it on my wishlist.
> >
> >> For those who want to play with this, configure2 alreay *has* a
> >> check_compatible_python() function. We commented out the call to this
> >> function (about line 935) since it was not reliable enough: having
> >> configure say a python is OK when it is not is quite annoying and
> confusing.
> >
> > Agreed - that's worse from a user standpoint for certain.
> >
> >> Knowing I'm repeating myself: we *really* don't want users installing
> >> packages into their existing python just to install Amber. There is too
> >> much danger of creating incompatibilities with other things that require
> >> python: that is, we increase the danger that installing Amber breaks
> >> something else on the user's computer. [numpy, in particular, exists in
> >> several incompatible releases; it is quite easy for program A to require
> >> version 1.9 and program B to require version 1.10. We can't solve that
> >> problem, but should not make it worse, either.]
> >
> > This is one of the gotchas of living in the python universe. Advanced
> > users can just use the '--with-python' flag. "Normal" users can have a
> > built-in miniconda. We just have to make it clear during configure
> > time exactly why miniconda is a good idea instead of the vague "well,
> > maybe stuff won't work" message of the past.
> >
> >>> 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).
> >
> > I was being a bit facetious about having to specify an extra flag :-)
> > - that stuff doesn't come through in email sometimes. I think the
> > '--with-python' flag is the correct solution.
> >
> >>>> [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).
> >>
> >> Has anyone tried to just make a shadow directory (using "cp -as" or
> lndir),
> >> with links to a clean amber tree, then build in the shadow directory?
> >
> > Unfortunately, this can't work for multiple parallel library/CUDA
> > version builds (maybe I'm not understanding what you mean).
> >
> >> Realistically, I'd recommend bigger disks. You can get 500 Gb external
> >> SSD drives with USB-3 or USB-C interconnects that are quite fast and
> will
> >> allow you create all the Amber images you are ever likely to need....
> >
> > Just because disk space is cheap doesn't mean we should be wasteful. I
> > would like to do with Amber what I can do with every other linux
> > source code package: have one giant source directory that I can point
> > to an install directory with '--prefix', and then that install
> > directory contains only what I need to run that version of Amber.
> > AMBERHOME can point to the common source, but PATH and LD_LIBRARY_PATH
> > point to the install directory. If I happen to get free time before
> > now and the code freeze maybe I'll take another crack at making this
> > happen.
> >
> > -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 Thu Dec 22 2016 - 09:30:02 PST
