hi
On Wed, Dec 21, 2016 at 1:28 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
wrote:
> Hi,
>
> Let's follow my suggestion of modeling our support for
> python package managers and packages like we support
> compiler vendors and language standards.
>
Besides consistency, what's the real benefit of doing that with python?
>
> On Wed, Dec 21, 2016 at 12:29:02PM -0500, David Case wrote:
> > trying to provide advice to users on how they can install missing items
> > is probably impossible--do we have them use pip, conda, apt-get, manual
> > download, something else?
>
> From my state of python ignorance the obvious candidates for
> amber supported python package managers are pip and conda.
> According wikipedia most pythons come with pip preinstalled;
> we are already using conda.
>
> On Wed, Dec 21, 2016 at 12:34:48PM -0500, Hai Nguyen wrote:
> > On Wed, Dec 21, 2016 at 12:25 PM, Scott Brozell <
> sbrozell.rci.rutgers.edu>
> > >
> > > > To avoid spending time on debug different Python distributions, we
> just
> > > > force user to use Miniconda (much lighter than Anaconda) as we ...
> > >
> > > This seems to be a different standard than we apply to other source
> > > languages; for example, we do not force gnu compilers, but rather
> > > support several vendors. And we try to advance to the next official
> > > language standards only when all or most vendors support that standard.
> > >
> > My language is quite extreme here. "force" should be "suggest".
> > User absolutely does not need to use Miniconda, they just need to specify
> > --with-python flag.
>
>
> Regarding amber supported python packages, what packages do we currently
> use ?
>
hard requirement: numpy
optional: maptlolib, ipython notebook, scipy
> If you can call that set Miniconda then why isn't it trivial for us to
> support Anaconda as well since Anaconda is a superset of Miniconda ?
>
because Anaconda is much bigger than Miniconda. Remeber that not all amber
developers were very pleased with the flood of installing miniconda package.
So won't be Anaconda.
The point here is: Miniconda comes with conda for package manager. If users
want to add anything, they just need to
'amber.conda install some_package". This syntax is the same for different
platform (forget about apt-get, yum, ...)
>
> Treating the package list like a language standard would presumably be
> very useful not just for installing Amber but also for programming.
>
I don't see how this apply to Python case. If you do not need to remember
anything, just install numpy for hard requirement.
>
>
> Why should we model our support for python package managers and
> packages like we support compiler vendors and language standards?
> Because supporting more than one compiler vendor and sticking to
> language standards has improved our software, so following that
> model for our python software might reap similar benefits.
>
> I am trying to apply the scientific method to our python woes.
>
> Heretofore, it seems like the approach has been we use Miniconda and
> for anything else the onus is on you to hack via --with-python because
> your python might be screwed up.
>
>
Exactly. Just because we don't have resources to do protocol C (or D) in
Dave email.
Anyone is welcome to do that but I myself will be stick with Miniconda.
Why?
- it's super easy to install (either via GUI or command line). We've been
using it for our continuous integration.
- it comes with conda, a great Python package builder and manager for
Python C/C++ extension. pip is only good for pure Python code, which is not
applied for amber
- It's norm and wildly used in scientific community.
- I hate to use "sudo". (vs apt-get, yum, ...).
- We (Dave, me) are thinking about distributing AmberTools binary code via
conda to bring it closer to phenix and rosseta community.
Hai
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Dec 21 2016 - 11:00:02 PST
