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.
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.
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.]
> 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).
Please try my idea of making $AMBERHOME/miniconda a link to your real
python installation. At least then, if you move python, all you have to do is
update the links. And you won't need to remember "another configure flag".
Another thing I think we should be doing (after some testing!): have
configure2 issue a "conda clean --all" directive. That removes about 2/3
of the size of my miniconda installation.
>
> > [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?
But this doesn't solve the problem of how to keep the shadow directory up
to date as files are added or deleted from the original amber tree.
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....
...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 21 2016 - 19:30:02 PST
