So does this mean we are officially dropping RHEL 6 support?
> On Feb 6, 2017, at 02:06, Hai Nguyen <nhai.qn.gmail.com> wrote:
>
> It seems to me that your system has only python <= 2.6?
>
> In AT17, the --skip-python still use Python for some programs. Basically we
> wrap some programs requiring AMBERHOME
> at run time (e.g nab, tleap, ...) by using a python script.
>
> The script AmberTools/conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py
> will update the binary files in $AMBERHOME/bin
>
> Why do we do that? Because we are thinking about distribute
> binary-AmberTools too (mostly via conda). We only need
> user to "conda install ambertools -c ambermd" and just it, user do not need
> to do anything else (even source amber.sh).
>
> I probably need to fix copy_and_post_process_bin.py so it can be run with
> any python version.
>
> (worked fine with my python 3.5 on macos
>
> ./configure --prefix ~/try_amber_no_python/ --skip-python -macAccelerate
> clang
>
> )
> cheers
> Hai
>
> On Mon, Feb 6, 2017 at 1:16 AM, Scott Brozell <sbrozell.rci.rutgers.edu>
> wrote:
>
>> Hi,
>>
>> In a fresh repo of the master:
>> ./configure -mkl --skip-python intel
>> make
>> ...
>> make[2]: Leaving directory `/tmp/amber/AmberTools/src/nfe-umbrella-slice'
>> (if [ "yes" = "no" ]; then \
>> make python_serial ;\
>> fi;\
>> )
>> (python conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py
>> /tmp/amber/bin /tmp/amber/bi
>> n)
>> Traceback (most recent call last):
>> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
>> line 228, in <module>
>> main()
>> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
>> line 224, in main
>> script_template=script_template)
>> File "conda-recipe/scripts/patch_amberhome/copy_and_post_process_bin.py",
>> line 158, in copy_to_targe
>> t_folder
>> print('patching {}'.format(final_exe_path))
>> ValueError: zero length field name in format
>> make[1]: *** [serial] Error 1
>> make[1]: Leaving directory `/tmp/amber/AmberTools/src'
>> make: *** [install] Error 2
>>
>> On Sat, Feb 04, 2017 at 08:24:01PM -0500, Hai Nguyen wrote:
>>> after some testings, I go head merging my change for --prefix option to
>>> master branch.
>>>
>>> Those commits should not affect your regular workflow (hopefully) but if
>>> any, please let me know (or even better if make a new commit to fix :D).
>>>
>>> Usage example: You can try different compilers by
>>>
>>> mkdir $HOME/try_amber_prefix
>>> cd amber17
>>> ./configure --prefix $HOME/try_amber_prefix gnu
>>> source amber.sh
>>> make install
>>>
>>> After the regular install, all installed files will be in
>>> $HOME/try_amber_prefix.
>>>
>>> Of course, to run programs in try_amber_prefix folder, you still need to
>>> source $HOME/try_amber_prefix/amber.sh
>>>
>>> Expected failures if running the tests for "--prefix" option:
>>> FEW.pl: I don't know Perl well to make change, so just let it be.
>>> pymsmt: It's using some library in its source folder at run time. I think
>>> Pengfei is working on this.
>>>
>>> Hai
>>>
>>> On Thu, Feb 2, 2017 at 1:05 PM, Hai Nguyen <nhai.qn.gmail.com> wrote:
>>>
>>>> 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.
>>
>> _______________________________________________
>> 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 06 2017 - 05:00:02 PST
