thanks. I will look at the Python stuff.
Should expect not able to run some (most?) tests (even if copying
$AMBERHOME/test and AmberTools/test to $PREFIX)
since some of the tests point to the source folder.
cheers.
Hai
On Thu, Feb 2, 2017 at 1:02 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> PS - The 'prefix' install was 328MB, compared to 2.5 GB for a full
> Amber 16 install. Very nice.
>
> On Thu, Feb 2, 2017 at 1:00 PM, Daniel Roe <daniel.r.roe.gmail.com> wrote:
> > Got a chance to try this today. I haven't tested thoroughly but it
> > seems to work well. Nice work Hai!
> >
> > I hit a brief hiccup during my initial attempt with python stuff:
> > ```
> > Checking .pth file support in
> > /u/droe/Amber/TEMP/prefix/lib/python2.7/site-packages/
> > /mnt/local/droe/anaconda2/bin/python -E -c pass
> > TEST FAILED: /u/droe/Amber/TEMP/prefix/lib/python2.7/site-packages/
> > does NOT support .pth files
> > error: bad install directory or PYTHONPATH
> > ```
> > It went on to describe the problem and potential solutions which was
> > really nice, but the real issue was I had forgotten to source amber.sh
> > - that fixed the problem. So maybe that could be the first thing you
> > suggest for potential solutions?
> >
> > -Dan
> >
> >
> > On Wed, Jan 25, 2017 at 3:48 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
> >> Oops, no "="
> >>
> >> ./configure --prefix $HOME/try_another_folder gnu
> >>
> >> On Wed, Jan 25, 2017 at 3:31 PM Hai Nguyen <nhai.qn.gmail.com> wrote:
> >>
> >>> > If I happen to get free time before
> >>> now and the code freeze maybe I'll take another crack at making this
> >>> happen.
> >>>
> >>> .Dan: I have working code in amber_prefix_Hai branch. Feel free to try
> and
> >>> update that.
> >>>
> >>> ./configure --prefix=$HOME/try_another_folder gnu
> >>>
> >>> Hai
> >>>
> >>> On Thu, 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
> >
> >
> >
> > --
> > -------------------------
> > 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
>
>
>
> --
> -------------------------
> 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 Feb 02 2017 - 10:30:03 PST
