David,
Your long-winded response is very helpful to me. In fact, I'm a python
agnostic, whose only credo is "whatever kldge works!"!
Currently I have three python instances (in addition to anber's);
v.27and 3.4 via Synaptic from the Ubuntu repository; v. 3.5 indeed from
Anaconda (whose directory layout is distinct from the repository
layout.) My approach has been a set of "use_python_<version>"-scripts
to tailor executables and environmental-variables to what I think is a
particular program's needs; in amber's case for python v.2.7.
Following the cue of "amber.sh/amber.csh", I'm inclined to rethink my
approach, and to create "setup-<program)"-scripts, at least fro the
python-dependent programs I use regularly.
The situation is somewhat analogous to that with java. With java there
is the "update-java-alternatives" script, which re-links java
executables for a specific version.
I suppose what I could really use would be a sort of python primer, not
so much on the language syntax, but on these general issues of module
search paths, etc.
Bob W.
On 5/21/17 12:38 AM, David Case wrote:
> On Sat, May 20, 2017, Robert Wohlhueter wrote:
>> Thanks for your responses. They were helpful, and I got "analyse.sh"
>> working.
>>
>> That my system python is "bad" is a relative statement: I have dozens
>> of programs that use python, some requiring version x, another version y
>> (and some, like amber which distributes their own version). And I admit
>> to a baroque set of scripts and aliases to try to satisfy each
>> pthon-dependent-application.
>>
>> The most expedient solution for me was simply to replace the
>> synaptic-distribution-numpy version of _umath_linalg.so with the Amber16
>> version. (Hopefully, that won't break other numpy-dependent programs.
>> But is it does, I'm sensitized.)
> I know that these can be quasi-religious items for people in the python
> community. Here's my view, which may have serious flaws:
>
> Various python incompatibilities (versions of the interpreter
> itself, numpy versions....) have led many programs in our field
> to distribut a version of python along with their codes, and use
> that, avoiding dependence on the "system" python.
>
> This approach is simplified by the anaconda/miniconda approach, which now
> allows us to ask users to install a python that we know works with Amber.
> Strong objections from key people have prevented us from making this a
> requirement, however. And some examples and tutorials have made the
> assumption that the "python" found first in the PATH is the one to use, even
> if there is also an "amber.python" in the PATH. The latter is both more
> likely to work, and is certainly easier to debug than an unknown system
> python. Using amber.python should also discourage people from replacing
> a system-wide numpy component with something else, with potentially bad
> consequences for other programs.
>
> I'm cc-ing this to the developers mailing list. My recommendation is
> that we re-double our efforts to have users install a python inside the
> $AMBERHOME tree, and access it via the "amber.python" alias. Programs,
> examples and tutorials should consider using amber.python as the
> interpreter, only falling back on "/usr/bin/env python" if the former
> doesn't exist. This makes life a little less convenient for developers,
> but decreases the chances that users will find python-related problems
> in the first place, or that they may adversely affect non-Amber work in
> trying to fix these problems.
>
> (Apologies for being so long-winded.)
>
> ....dac
>
>
>> Thanks again,
>>
>> Bob W.
>>
>> On 5/20/17 9:31 AM, David Case wrote:
>>> On Fri, May 19, 2017, Hai Nguyen wrote:
>>>
>>>> sounds like your system python is bad. Can you try to replace "python"
>>>> by "amber.python" (to use $AMBERHOME/miniconda python)?
>>> Sounds like this may already have been done:
>>>
>>>>> Using `find`, I also see an instance of this shared-lib in
>>>>> $AMBERHONE/miniconda/pkgs/numpy-1.12.0-py27_nomkl_0/lib/python2.7/site-packages/numpy/linalg/_umath_linalg.so.
>>>>> NONE of these instance defines the symbol
>>>>> "ATL_zttrsm" (as probed by `nm -Ca <lib-path-name> | grep ATL_zttrsm`)
>>> But if you haven't tried using amber.python, it's certainly worth a try.
>>>
>>>>> Any hints appreciated,
>>> I don't have any real hints, and I think this is the first time this problem
>>> has been reported.
>>>
>>> [Developers: we don't have any systematic way at all of keeping the
>>> tutorials in sync with the current code. Suggestions are welcome. Maybe
>>> new students/postdocs could be required to work through a tutorial,
>>> comment on problems or things that are difficult to understand, and post
>>> results to a wiki page? Other ideas might be better.
>>>
>>> It would be great if someone now could check tutorial A9.]
>>>
>>> ....dac
>>>
>>>
>>> _______________________________________________
>>> AMBER mailing list
>>> AMBER.ambermd.org
>>> http://lists.ambermd.org/mailman/listinfo/amber
>>>
>> _______________________________________________
>> AMBER mailing list
>> AMBER.ambermd.org
>> http://lists.ambermd.org/mailman/listinfo/amber
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sun May 21 2017 - 09:00:02 PDT
