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