[opensuse-packaging] Jupyter released -- new name for IPython project
Warning, long post ahead. Unfortunately this is a complicated issue, and I don't think our current policies will serve us well here. IPython is a rich python shell and python browser interface that has gained a lot of popularity, especially amongst scientific users. Python 2 and Python 3 versions have been supported in openSUSE:Factory and openSUSE releases for a long time. Over the past year or so, the project has been modularizing. The python-specific bits have been split out, the individual components have been spun off into individual projects that can be built, installed, and released independently. The last key missing piece, IPython 4.0, was released 2 days ago. With this, it is not possible to have a fully working jupyter installation. I am currently in the process of getting everything working for openSUSE, but due to a large number of new dependencies, updated dependency version requirements, and package interdependencies, it is going to take some time. I ask everyone else please hold off on trying to package them, it really requires a coordinated approach and I have a specific packaging system in mind: In order to keep things consistent, I want to name jupyter-specific components with the naming convention "python-jupyter_<name>" and "python3-jupyter_<name>", where "<name>" is the package name (unless the package name is already "jupyter_<something>", in which case it uses "python-<name>"/"python3-<name>"). This is not exactly in line with the current Python packaging, but because Jupyter has so many components, I think it would be a nightmare if they weren't named in a consistent manner, and unfortunately the upstream naming is far from consistent. This naming convention normally only applies to package that are useless outside of jupyter. I would like this naming convention to be formally included in the python packaging guidelines, because there is already dozens of kernels for jupyter, and dozens of additional add-ons, and more of both are coming constantly. We are going to end up with a huge mess if we don't get things nailed down correctly up-front. Initially, I will get a minimum set of jupyter packages running and submitted to openSUSE:Factory, as defined by the "jupyter" package (I use "python-" here, but "python3-" versions will be submitted in parallel): * python-ipython_genutils - Generic utilities copied from IPython. Upstream name: ipython_genutils * python-traitlets - A configuration system. Part of the jupyter project but usable elsewhere. Upstream name: traitlets * python-jupyter_core - The core of jupyter. All jupyter components rely on this. Useless to users on its own. Upstream name: jupyter_core * python-jupyter_client - Libraries used by jupyter clients and kernels. Useless to users on its own. Upstream name: jupyter_client * python-jupyter_ipython - IPython components. This was the "ipython" package, but, most useful stuff has been moved out of it. Now useless to users on its own. Upstream name: ipython. * python-jupyter_ipykernel - the IPython kernel for jupyter. Again, useless on its own. Upstream name: ipykernel. * python-jupyter_nbformat - API for working with the jupyter browser interface. Useless on its own. Upstream name: nbformat, but there is also a "jupyter_ nbformat" project, owned by the same group, but with no files. * python-jupyter_nbconvert - Convert jupyter browser interfaces to other formats. This is useful for users, but requires everything listed above. Upstream name: nbconvert, but there is also a "jupyter_ nbconvert" project, owned by the same group, but with no files. * python-jupyter_notebook - the jupyter browser interface. This is useful for users, but requires everything listed above. Upstream name: notebook, but there is also a "jupyter_notebook" project, owned by the same group, but with no files. * python-jupyter_console - the jupyter console interface. This is useful for users, but requires everything listed above except the notebook stuff. Upstream name: jupyter_console. * python-jupyter_qtconsole - the stand-alone qt console. This is useful for users, but requires everything listed above except the notebook stuff. Upstream name: qtconsole, but there is also a "jupyter_qtconsole" project, owned by the same group, but with no files. At this point I hope you are starting to see how naming consistency is an issue. * python-jupyter - upstream metapackage for setting up in a basic, working jupyter system. This package will provide and obsolete the existing "IPython" package, since it is the package that provides equivalent functionality. Upstream name: jupyter Once this is working, I will then get additional packages that provide existing ipython functionality working. With these in Factory we should be in a similar state to where we are now with IPython 3.x: * python-jupyter_ipywidgets - Interactive widgets for the notebook. Upstream name: ipywidgets * python-jupyter_ipyparallel - Parallel processing for jupyer. Upstream name: ipyparallel Once these are done, and a naming conventional is in the wiki, we can open things up and let people start submitting what they find useful. There are currently dozens of additional jupyter-related packages in pypi and many more coming. As for package homes, I think the best solution would be this: Generic components live in devel:languages:python / devel:languages:python3. That is the language these components are written in. Packages provided by the jupyter project should be in openSUSE:Factory, but third-party add-ons should be looked at on a case-by-case basis. Kernels for other languages should live in the home project of those languages, and be linked in devel:languages:python / devel:languages:python3. If those languages are in openSUSE:Factory, their kernel should be as well once it has a stable release. Language-specific add-ons should live on the home project of that language, and do not need to be linked anywhere else but optionally can be. Does this approach seem reasonable to everyone? Comments, criticisms, suggestions? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Warning, long post ahead. Unfortunately this is a complicated issue, and I don't think our current policies will serve us well here.
IPython is a rich python shell and python browser interface that has gained a lot of popularity, especially amongst scientific users. Python 2 and Python 3 versions have been supported in openSUSE:Factory and openSUSE releases for a long time.
Over the past year or so, the project has been modularizing. The python-specific bits have been split out, the individual components have been spun off into individual projects that can be built, installed, and released independently.
The last key missing piece, IPython 4.0, was released 2 days ago. With this, it is not possible to have a fully working jupyter installation.
I am currently in the process of getting everything working for openSUSE, but due to a large number of new dependencies, updated dependency version requirements, and package interdependencies, it is going to take some time. I ask everyone else please hold off on trying to package them, it really requires a coordinated approach and I have a specific packaging system in mind:
In order to keep things consistent, I want to name jupyter-specific components with the naming convention "python-jupyter_<name>" and "python3-jupyter_<name>", where "<name>" is the package name (unless the package name is already "jupyter_<something>", in which case it uses "python-<name>"/"python3-<name>"). This is not exactly in line with the current Python packaging, but because Jupyter has so many components, I think it would be a nightmare if they weren't named in a consistent manner, and unfortunately the upstream naming is far from consistent. This naming convention normally only applies to package that are useless outside of jupyter. I would like this naming convention to be formally included in the python packaging guidelines, because there is already dozens of kernels for jupyter, and dozens of additional add-ons, and more of both are coming constantly. We are going to end up with a huge mess if we don't get things nailed down correctly up-front.
Initially, I will get a minimum set of jupyter packages running and submitted to openSUSE:Factory, as defined by the "jupyter" package (I use "python-" here, but "python3-" versions will be submitted in parallel):
* python-ipython_genutils - Generic utilities copied from IPython. Upstream name: ipython_genutils
* python-traitlets - A configuration system. Part of the jupyter project but usable elsewhere. Upstream name: traitlets
* python-jupyter_core - The core of jupyter. All jupyter components rely on this. Useless to users on its own. Upstream name: jupyter_core
* python-jupyter_client - Libraries used by jupyter clients and kernels. Useless to users on its own. Upstream name: jupyter_client
* python-jupyter_ipython - IPython components. This was the "ipython" package, but, most useful stuff has been moved out of it. Now useless to users on its own. Upstream name: ipython.
* python-jupyter_ipykernel - the IPython kernel for jupyter. Again, useless on its own. Upstream name: ipykernel.
* python-jupyter_nbformat - API for working with the jupyter browser interface. Useless on its own. Upstream name: nbformat, but there is also a "jupyter_ nbformat" project, owned by the same group, but with no files.
* python-jupyter_nbconvert - Convert jupyter browser interfaces to other formats. This is useful for users, but requires everything listed above. Upstream name: nbconvert, but there is also a "jupyter_ nbconvert" project, owned by the same group, but with no files.
* python-jupyter_notebook - the jupyter browser interface. This is useful for users, but requires everything listed above. Upstream name: notebook, but there is also a "jupyter_notebook" project, owned by the same group, but with no files.
* python-jupyter_console - the jupyter console interface. This is useful for users, but requires everything listed above except the notebook stuff. Upstream name: jupyter_console.
* python-jupyter_qtconsole - the stand-alone qt console. This is useful for users, but requires everything listed above except the notebook stuff. Upstream name: qtconsole, but there is also a "jupyter_qtconsole" project, owned by the same group, but with no files. At this point I hope you are starting to see how naming consistency is an issue.
* python-jupyter - upstream metapackage for setting up in a basic, working jupyter system. This package will provide and obsolete the existing "IPython" package, since it is the package that provides equivalent functionality. Upstream name: jupyter
Once this is working, I will then get additional packages that provide existing ipython functionality working. With these in Factory we should be in a similar state to where we are now with IPython 3.x:
* python-jupyter_ipywidgets - Interactive widgets for the notebook. Upstream name: ipywidgets
* python-jupyter_ipyparallel - Parallel processing for jupyer. Upstream name: ipyparallel
Once these are done, and a naming conventional is in the wiki, we can open things up and let people start submitting what they find useful. There are currently dozens of additional jupyter-related packages in pypi and many more coming.
As for package homes, I think the best solution would be this: Generic components live in devel:languages:python / devel:languages:python3. That is the language these components are written in. Packages provided by the jupyter project should be in openSUSE:Factory, but third-party add-ons should be looked at on a case-by-case basis. Kernels for other languages should live in the home project of those languages, and be linked in devel:languages:python / devel:languages:python3. If those languages are in openSUSE:Factory, their kernel should be as well once it has a stable release. Language-specific add-ons should live on the home project of that language, and do not need to be linked anywhere else but optionally can be.
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions? I totally agree with you, just something like we actually do for Django
On 08/14/2015 10:38 AM, Todd Rme wrote: packages. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday, August 14, 2015 12:03:50 PM Benjamin Denisart wrote:
On 08/14/2015 10:38 AM, Todd Rme wrote:
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions?
I totally agree with you, just something like we actually do for Django packages.
Do you plan to split django? -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 14, 2015 at 12:38 PM, Alberto Planas <aplanas@suse.de> wrote:
On Friday, August 14, 2015 12:03:50 PM Benjamin Denisart wrote:
On 08/14/2015 10:38 AM, Todd Rme wrote:
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions?
I totally agree with you, just something like we actually do for Django packages.
Do you plan to split django?
It looks like Django is a single tarball. The issue here is that all of the packages I listed are separate tarballs, with their own pypi pages and their own github projects. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday, August 14, 2015 12:03:50 PM Benjamin Denisart wrote:
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions? I totally agree with you, just something like we actually do for Django
On 08/14/2015 10:38 AM, Todd Rme wrote: packages. Do you plan to split django? It looks like Django is a single tarball. The issue here is that all of the packages I listed are separate tarballs, with their own pypi
On Fri, Aug 14, 2015 at 12:38 PM, Alberto Planas <aplanas@suse.de> wrote: pages and their own github projects. What I mean is that Django modules (separate packages) are named
On 08/14/2015 12:45 PM, Todd Rme wrote: python-django-$something. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday, August 14, 2015 12:47:08 PM Benjamin Denisart wrote:
What I mean is that Django modules (separate packages) are named python-django-$something.
Django modules or django applications? For django applications my +1 for the naming schema. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/14/2015 12:49 PM, Alberto Planas wrote:
On Friday, August 14, 2015 12:47:08 PM Benjamin Denisart wrote:
What I mean is that Django modules (separate packages) are named python-django-$something. Django modules or django applications?
For django applications my +1 for the naming schema.
We apply django naming convention for both, I think. That's why I think Todd approach is the best : it's logical. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Friday, August 14, 2015 10:38:39 AM Todd Rme wrote:
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions?
Your proposal is quite outstanding, and can deliver a very high quality jupyter package for openSUSE. My approach will be much more simplistic: * python-jupyter_ipython: contain gentuils, traitles, core, client, console and ipykernel (?). This will provide the classical console iPython. * python-jupyter_qtconsole: depends on python-jupyter_ipython * python-jupyter_notebook: contains also nbformat * python-jupyter_nbconvert: Good idea to put it alone, AFAIK this will depend on pandoc and haskell I am not sure that many people will demand python-traitlets apart from juputer itself. Anyway, your solution is quite superior. -- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 14, 2015 at 12:48 PM, Alberto Planas <aplanas@suse.de> wrote:
On Friday, August 14, 2015 10:38:39 AM Todd Rme wrote:
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions?
Your proposal is quite outstanding, and can deliver a very high quality jupyter package for openSUSE. My approach will be much more simplistic:
* python-jupyter_ipython: contain gentuils, traitles, core, client, console and ipykernel (?). This will provide the classical console iPython.
* python-jupyter_qtconsole: depends on python-jupyter_ipython
* python-jupyter_notebook: contains also nbformat
* python-jupyter_nbconvert: Good idea to put it alone, AFAIK this will depend on pandoc and haskell
I am not sure that many people will demand python-traitlets apart from juputer itself.
Anyway, your solution is quite superior.
Sorry, perhaps I wasn't clear. The problem is that every package I listed is a separate upstream package, with its own tarball, own pypi page (or two), own github project, etc. So ipython_genutils is one upstream package, traitlets is another upstream package, nbformat is another, notebook is another, etc. There is no longer any individual upstream "jupyter" package. Well, there is, but it is just a metapackage, it contains essentially no source code itself, it just depends on these other packages (or depends on one of these packages, which in turn depends on another). So I am just following the upstream package breakdown. One tarball per rpm. The only thing really up to us is what we call these packages, and how we organize them across the different openSUSE repositories. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Freitag, 14. August 2015 schrieb Todd Rme:
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions?
It looks a bit strange to mix - and _ in the package name. Therefore I'd propose package names like python-jupyter-something instead of python-jupyter_something. Besides that, your proposal looks good and makes sense. Regards, Christian Boltz -- Because dirkmueller is bugowner and two times maintainer (wow!) it seems he is three times responsible (WOW!) in contrast to you, you are only responsible (i.e. only ordinary one times responsible ;-) [Johannes Meixner in opensuse-packaging about an osc maintainer output] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/17/2015 05:57 PM, Christian Boltz wrote:
Hello,
Am Freitag, 14. August 2015 schrieb Todd Rme:
Does this approach seem reasonable to everyone? Comments, criticisms, suggestions?
It looks a bit strange to mix - and _ in the package name. Therefore I'd propose package names like python-jupyter-something instead of python-jupyter_something.
While I tend to agree that consistency of using "-" or "_" may provide a better aesthetic experience, I think consistency with the upstream project in the name has a higher priority. If the upstream names use "_" as word separator I think we should stick to it.
Besides that, your proposal looks good and makes sense.
+1 on the overall proposal. As far as adding things to the packaging guideline I think it should be written in a generic fashion, i.e. rather than write about jupyter write as "any system that is logically contained but provides it's functionality in multiple upstream projects with separate releases cyslces and tarballs, see jupyter and django as examples" My $0.02 Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo
participants (5)
-
Alberto Planas -
Benjamin Denisart -
Christian Boltz -
Robert Schweikert -
Todd Rme