[IPython-dev] Docker IPython

Andrew Gibiansky andrew.gibiansky at gmail.com
Tue Aug 5 12:01:06 EDT 2014


Pip please :) Conda is fairly non-standard in the Python ecosystem in my
experience; it's common for data analysis and IPython sort of things, but
pip is the more common packaging standard. Though pip is less powerful than
conda, it has the benefits that *every* Python developer knows its use, and
I think it's much more appropriate for the base IPython notebook docker
file.

Again, this is from the view that I want the IPython notebook docker build
as a *base* for something non-Python related; so I *just* want the bare
essentials required for IPython itself, and nothing more. Conda seems like
it is adding more than you really need, whereas pip does that. It may make
sense to have the Python-based derived notebook (the one that includes
scipy and so on) to use Conda, though. (Not sure how well pip and conda
mix.)

-- Andrew


On Tue, Aug 5, 2014 at 8:53 AM, Kyle Kelley <rgbkrk at gmail.com> wrote:

> Wes,
>
> Responses inline.
>
>
> On Tue, Aug 5, 2014 at 1:00 AM, Wes Turner <wes.turner at gmail.com> wrote:
>
>>
>> On Tue, Aug 5, 2014 at 12:46 AM, Tyler Erickson <tylere at google.com>
>> wrote:
>>
>>>
>>> On Mon, Aug 4, 2014 at 10:33 PM, Kyle Kelley <rgbkrk at gmail.com> wrote:
>>>
>>>> Tyler,
>>>>
>>>> Taking in everyones comments and my opinion as a not-quite-sysadmin:
>>>>
>>>> Base image, ipython/notebook, will
>>>>
>>>> * have just the ipython notebook essentials
>>>> * up to date (as of image build) version of pip (or conda... plead for
>>>> one or the other please!)
>>>>
>>>
>>> conda, please :)
>>>
>>
>> +1. http://conda.pydata.org/docs/build.html
>>
>>
>>>
>>>
>>>> * be installed for all users (all users inside the container)
>>>>   * This means that any images inheriting from it can set up their own
>>>> user setup, install more packages
>>>>
>>>
>>> Sounds fine to me.
>>>
>>>
>>>>  * default cmd that runs the notebook server with some default
>>>> parameters
>>>>   * This can be overwritten by a Dockerfile that uses FROM
>>>> ipython/notebook
>>>>
>>>> My personal take on this is that we could have an ipy user, with
>>>> notebooks at /home/ipy/notebooks.
>>>>
>>>
>>> Sounds reasonable. I have no strong opinion.
>>>
>>>
>>>>  Derivative image, ipython/scipystack (please suggest other names),
>>>> could be
>>>>
>>>> * numpy
>>>> * scipy
>>>> * matplotlib
>>>> * pandas
>>>> * scikit-learn
>>>>
>>>
>>> I would be happy with that list.
>>>
>>
>> * [ ] pip (which version?)
>>
>> * Supervisord? http://supervisord.org/
>> https://github.com/Supervisor/initscripts
>>
>
> Why? The process can be kept up inside the container and managed outside
> of the container. Does this grant something else?
>
>
>>
>> * conda https://pypi.python.org/pypi/conda
>>
>> * enpkg https://pypi.python.org/pypi/enstaller
>>
>
> That's just making things more complicated. Would you be able to pip
> install or conda install this if you really need it?
>
>
>>
>>
>> * pyenv https://github.com/yyuu/pyenv
>>
>
> No thank you. Switching kernels will be done inside the notebook itself.
>
>
>>
>> * tox, {... build packages }
>>
>
> tox is out of scope to me. What is your reasoning and audience?
>
>
>>
>> * { ad infinitum }
>>
>>
>>>
>>> Cheers,
>>> Tyler
>>>
>>>
>>>
>>>> For an IHaskell base image, I'd prefer the namespace to actually be
>>>> jupyter/ihaskell in the long run.
>>>>
>>>> There may come a time when we want multiple kernels in one container.
>>>> After all, have you seen what you can do with the current master branch?
>>>>
>>>>
>>>>
>>>>
>>>> Including all the kernels (and stacks) will make a hefty docker image
>>>> though, so I won't progress down that path just yet.
>>>>
>>>>
>>>>
>>>> On Mon, Aug 4, 2014 at 4:52 PM, Tyler Erickson <tylere at google.com>
>>>> wrote:
>>>>
>>>>> Kyle,
>>>>>
>>>>> I think having an official base Docker instance will be quite useful,
>>>>> especially for running workshops.
>>>>>
>>>>> I added comments for my particular use case below.
>>>>>
>>>>> On Fri, Aug 1, 2014 at 6:54 PM, Kyle Kelley <rgbkrk at gmail.com> wrote:
>>>>>
>>>>>> Earlier this week we released an experimental base Docker image for
>>>>>> the IPython notebook:
>>>>>>
>>>>>> https://registry.hub.docker.com/u/ipython/notebook/
>>>>>>
>>>>>> As well as a Docker image for the notebook viewer (which will be used
>>>>>> in production soon):
>>>>>>
>>>>>> https://registry.hub.docker.com/u/ipython/nbviewer/
>>>>>>
>>>>>> Yay!
>>>>>>
>>>>>> Several folks have reached out about these images, and I'd like to
>>>>>> get a conversation started amongst those that want to build from a common
>>>>>> base. There are, after all, a *lot* of ipython images up on Docker already.
>>>>>> Additionally, there is a LONG thread on the software carpentry mailing list
>>>>>>
>>>>>> There are some open questions from me:
>>>>>>
>>>>>> * Who should the user be inside the container?
>>>>>>   * Should they be able to install more packages?
>>>>>>
>>>>>
>>>>>  I don't think the user accessing the instance needs to be able to
>>>>> install custom packages. (It would be nice this functionality was
>>>>> available, but it is not critical for running workshops.)
>>>>>
>>>>> However, administrators need to have the ability to create custom
>>>>> images based off the docker base image that have additional packages.
>>>>>
>>>>>
>>>>>>   * In a chef cookbook and deployment setup, I just made the user
>>>>>> named ipynb.
>>>>>>
>>>>>> * Is it ok to force HTTPS?
>>>>>>   * If we do, we're stuck with self signed certs or requiring them to
>>>>>> provide them on run
>>>>>>   * This isn't really the right way to compose applications with
>>>>>> Docker and probably makes things problematic for anyone building on top of
>>>>>> ours
>>>>>>
>>>>>> * Who is our target audience?
>>>>>>   * People deploying notebooks across their organization for users?
>>>>>>   * Students (and their teachers) wanting access to an easy analytics
>>>>>> environment?
>>>>>>
>>>>>
>>>>> My interest is in providing an environment for external users of our
>>>>> analysis API, so it somewhat similar to the latter description. Some are in
>>>>> academia, but many are not.
>>>>>
>>>>> * What would you see out of a base image? Where would the value be?
>>>>>>
>>>>>> * Would people like to see a bleeding latest image that you can spin
>>>>>> up to see the current state of the IPython notebook by just running `docker
>>>>>> run ipython/notebook:bleeding-latest`?
>>>>>>
>>>>>> * Do people want a base image that has a large portion of the scipy
>>>>>> stack?
>>>>>>
>>>>>
>>>>> Yes, particularly matplotlib and pandas.
>>>>>
>>>>> Cheers,
>>>>>  Tyler
>>>>>
>>>>> I'll stop with these and see where the discussion takes us.
>>>>>>
>>>>>> _______________________________________________
>>>>>> IPython-dev mailing list
>>>>>> IPython-dev at scipy.org
>>>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>
>>>
>>
>> _______________________________________________
>> 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/20140805/972075d5/attachment.html>


More information about the IPython-dev mailing list