[IPython-dev] Docker IPython

Wed Aug 6 12:03:03 EDT 2014

Hi,

as one of the IPython-Galaxy [1] developers we had such a similar
discussion about our IPython-docker image.

I really think we need to define you target audience. Imho, for an IPython
base Image our target audience it quite small. It should deliver a stable
and maintained IPython container. So everyone can build on-top of it.
Later we can build a second container, derived from it, with a full
installed scientific stack for teaching and so on ...

If you include to many tools it will not be used by many developers as base
image because to many peoples will disagree with your decision.

I would vote for a real basic set ... even the scipy stack is really
questionable for a "base image". If we go with the scipy stack than I would
reference the scipy community:

http://www.scipy.org/stackspec.html

Keep it small but stable, care about updates and documentation and let
other grow on top of your image.

Cheers,
Bjoern

[1] https://github.com/bgruening/galaxy-ipython

2014-08-06 8:36 GMT+02:00 Kyle Kelley <rgbkrk at gmail.com>:

> Brian, that is right in line with what I'd like to see. +1000
>
> > Question, do docker images have ways of pulling from multiple parents?
>
> Docker images can only have a single parent.
>
>
> On Tue, Aug 5, 2014 at 11:46 PM, Brian Granger <ellisonbg at gmail.com>
> wrote:
>
>> I think a more useful way of approaching this would be to ask the
>> following: what layers of docker images are useful? Here are some
>> ideas:
>>
>> Base: ipython and its deps, installed using system packages or pip
>> Base+SciPy: Base plus the extended scipy stack installed using system
>> packages or pip
>> Base+R kernel
>> Base+Julia kernel
>> ...
>> Conda/Anaconda version: ipython and deps installed using conda. We
>> should talk to Continuum about this
>>
>> Question, do docker images have ways of pulling from multiple parents?
>>
>> Cheers,
>>
>> Brian
>>
>> On Tue, Aug 5, 2014 at 9:34 PM, Geoff Oxberry <goxberry at gmail.com> wrote:
>> > In case chiming in matters, I'm vehemently opposed to conda in a base
>> image,
>> > because I think conda would be a great package manager if it didn't try
>> to
>> > do too much (as of Anaconda 1.9, it was also managing Python version,
>> and
>> > managing/creating virtualenvs). If it's in an "extended" derivative
>> image,
>> > that's fine by me. I agree that pip is more standard, and conda is good
>> for
>> > installing things (and only good for installing things).
>> >
>> >
>> > On Tue, Aug 5, 2014 at 6:40 PM, Dave Hirschfeld <
>> dave.hirschfeld at gmail.com>
>> > wrote:
>> >>
>> >> Fernando Perez <fperez.net <at> gmail.com> writes:
>> >>
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Aug 5, 2014 at 11:11 AM, Thomas Kluyver <takowl <at>
>> gmail.com>
>> >> wrote:If you call it scipystack, please put Sympy and nose in as well
>> - a
>> >> long and heated discussion last year settled on a core set of packages
>> >> that distributions describing themselves as shipping the Scipy Stack
>> >> should include:http://www.scipy.org/stackspec.html
>> >> >
>> >> >
>> >> > +1. Let's use the 'scipy stack' term as per the above.
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > I actually would vote for the 'extended' stack, that includes a few
>> >> packages that in the real world lots of people do use/need, like
>> >> sklearn/image. Here's a slightly outdated version of that:
>> >> >
>> >> >
>> >> >
>> https://speakerdeck.com/fperez/pydata-2013-keynote-ipython-and-friends?
>> >> slide=8
>> >> >
>> >> >
>> >> > Today I'd probably drop Mayav/PyTables (too specialized) but add
>> >> Seaborn (lightweight, easy, plays beautifully with pandas).
>> >> >
>> >> > That would make a very compelling image out of the box, with minimal
>> >> additional complexity (while there's extension code in those, none of
>> >> them are harder than scipy itself).
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Cheers,
>> >> >
>> >> > f-- Fernando Perez ( <at> fperez_org; http://fperez.org)
>> >>
>> >> PyTables could be handy as it's an optional dependency for pandas which
>> >> IIUC allows you to store pandas objects in hdf5 via the HDFStore which
>> is
>> >> becoming a very common way to store pandas objects.
>> >>
>> >> -Dave
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> IPython-dev mailing list
>> >> IPython-dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>> >
>> >
>> >
>> > --
>> > Geoffrey Oxberry, Ph.D., E.I.T.
>> > goxberry at gmail.com
>> >
>> > _______________________________________________
>> > IPython-dev mailing list
>> > IPython-dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/ipython-dev
>> >
>>
>>
>>
>> --
>> Brian E. Granger
>> Cal Poly State University, San Luis Obispo
>> @ellisonbg on Twitter and GitHub
>> bgranger at calpoly.edu and ellisonbg at gmail.com
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>
>
>
> --
> Kyle Kelley (@rgbkrk <https://twitter.com/rgbkrk>; http://lambdaops.com)
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20140806/6c1e4c49/attachment.html>