> Another thing I think we should be doing (after some testing!): have
configure2 issue a "conda clean --all" directive.
updated and tested
> That removes about 2/3 of the size of my miniconda installation.
In my case, "that" only removes 1/3 of the size of my miniconda. Another
1/3 is due to scipy. :D
Hai
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.
>
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 21 2016 - 22:00:03 PST
