On Fri, Apr 5, 2019 at 8:11 AM Matěj Cepl
On 2019-04-05, 09:19 GMT, you wrote:
The same, however, is true of jupyter packages. Jupyter packages are not useful outside of a jupyter context. If you try to run them in a normal python interpreter they won't work. In many cases, the fact that they are even written in python is just an implementation detail (just like the fact that the "python" package is written in C is an implementation detail). This is different than essentially every other "python-foo" package. You can run a "python-django-foo" package in a normal python interpeter. django is just a dependency. So if we are talking about renames, I would be more included to drop the "python" prefix than the "jupyter" one. Given how the ecosystem has evolved, calling them "python" packages can be outright wrong.
a) I don't think deep arcane philosophical distictions on The True Nature™ of packages matter. It is more important that all those packages are Python enough to use python-rpm-macros macros, and use similar technology (BTW, if there are some Jupyter-specific macros which you would like to standardize upon, feel free to suggest them or add them to python-rpm-macros).
It isn't about philosophy, it is about broadcasting to users what the package is all about. There are lots of packages that use python-rpm-macros but don't use the "python-" prefix because those packages are meant to be used from the command line or as GUI applications rather than being used from the Python interpreter. We have a specific exception for such packages in the python naming rules. At the very least, I think jupyter packages that aren't meant to be used from the python interpreter should be fall under the same exception, for the same reason. The reason being, that calling that "python-" packages is confusing and misleading.
b) The line between Jypyter and non-Jupyter packages is really murky. https://pypi.org/project/ipdb/ (and related packages, https://pypi.org/search/?q=ipdb ) is one clear example of package which is widely used outside of the Jupyter universe.
If that is the case, then the exception wouldn't apply. We would have to make a judgement call. The line is also murky with the command-line tool exception since a lot of "python-" packages also provide command-line tools. In these situations we also have to make judgement calls.
However, when going through d:l:p:jupyter packages I can see other ones which are at least suspiciously non-Jypter-specific (and they even break your own naming policy) python-testpath, python-traitlets, python-traittypes, and perhaps some others.
Note that none of those have the "jupyter_" prefix. They are part of the devel:languages:python:jupyter project because they are created by the ipython/jupyter maintainers for the primary purpose of being used by ipython/jupyter and are developed under one of the ipython/jupyter github projects. But they are normal python packages so they don't have the prefix.
After thinking this through I am personally coming down pretty strongly in favor of dropping the "python-" part, and adding a "jupyter-" part with rules otherwise the same as the python rules. I think the "python-" part has become misleading over the past 4 years.
That's another possible solution, to move all those packages to let's say science:jupyter project or something. However, I don't think it is wise. It really doesn't resolve problem with packages which are truly Python packages and which should still follow Python packaging policy (including names).
I would probably keep everything in the devel:languages:python:jupyter project to simplify the packaging workflow. Again comparing to command-line tools without the "python-" prefix, we still have a bunch of those in the various devel:languages:python projects.
In general I guess none will care how the packages in jupyter are called as long as they can't be imported in python, but those that are importable and can/might be used by other depending packages it will not be easy to find the package given the non-standard name and people will try to introduce them again.
This.
Yea without this in place in my view the wiki policy still wins usability wise. The least the jupyter stuff should do is provide the pypi names as symbols for others to seach and install and the wiki should be updated to mention the rationale around this different naming. (Also all the tooling needs to be adapted to take this into account, which I wonder if it is time spent well for just ~60 pkgs).
I agree. So,
1. I don't think there is any problem when non-Python (and not python- named, e.g., https://github.com/google/evcxr/tree/master/evcxr_jupyter or https://irkernel.github.io/; BTW, it is a pitty we don't have the latter packaged, or https://github.com/JuliaLang/IJulia.jl) packages are in d:l:p:jupyter (or if the whole thing moves to science:jupyter), it doesn't matter that much. But python packages (i.e., using %python macros and especially importable by other python packages) should still follow Python packaging policy.
I would use the same standard we currently use for command-line tools. That is, if they "are not designed and planned to be used as [python] libraries", then they should be called with the jupyter- prefix. If they are, they should be called with the python- prefix. Note that this is different than right now. As you both pointed out, there are some packages that are more properly python packages. Those would be changed to follow normal python naming rules.
2. All this should be documented. I don't care if you add a paragraph or two to https://en.opensuse.org/openSUSE:Packaging_Python or you make your own https://en.opensuse.org/openSUSE:Packaging_Jupyter (referred by the former), but it should be documented somewhere.
Fair enough. I would add the following paragraph at the end of the naming policy section: Similarly, this policy doesn't apply to jupyter kernels, extensions, and similar packages that are not designed and planned to be used as libraries. If they are meant to be used exclusively within the confines of a jupyter environment, they should be called "jupyter-modulename" instead of "python-modulename", where "modulename" is still the the name of this module on the Python Package Index. Such packages must also provide the "python-modulename" package if they contain python code.
3. Tooling must be adapted, and I really don't think doing it for 60+ packages makes sense. I would rather help with renaming all those python-jupyter_ packages to python- ones.
In terms of python rpm macros, this shouldn't be a huge issue since jupyter-related packages should really be python3-only. If it is python interpreter-dependent in normal usage then it would be used as a python library, which means it should be packaged as a "python-" package. And the packages would follow the same "{prefix}-{pypi name}" pattern as normal python packages. So what would need to change is that the pypi update detection script would need to strip both the "python-" and "jupyter-" prefixes. Out of curiosity, how does the update detection script deal with command-line applications, or does it? As for the number, pypi lists 427 packages that fall under either the jupyter or ipython classifier, and 1,942 packages just from searching for "jupyter". And these numbers are growing fast. And as you pointed out, there are more elsewhere that aren't distributed through pypi. So although not all of these would fall under my proposed policy change, we are still talking about a potentially large chunk of packages. That we haven't had a chance to package a huge number of them yet is just due to a lack of manpower. And I do think a "jupyter" pattern would be worthwhile. There are a lot of packages that either are meant primarily to be used in jupyter while still being usable in python, and lots of packages that provide additional functionality when used in a jupyter environment. -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org