On 2019-04-05, 09:19 GMT, you wrote:
First, this seems like the sort of thing that should be discussed on the openSUSE python mailing list,
This is openSUSE Python mailing list, isn't it? So, that's exactly what we are doing, aren't we?
or at the very least with the jupyter project maintainer,
That's you, isn't it?
The first I heard that anyone had a problem with the current policy was when I got a delete request for a package.
Sorry, the only policy I have been aware of is https://en.opensuse.org/openSUSE:Packaging_Python and jupyter packages break it. Some email on some list long time before I have ever installed openSUSE is not policy in my understanding of things (yes, I used to be a lawyer, so I may be a bit too pedantic about formal stuff). I have really never heard about it. However, let's not get bogged down in this formalism. Whatever the current policy is, let us agree on how to go on forwards and make appropriate changes.
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). 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. 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.
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).
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. 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. 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. What do you think? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 If we rise from prayer better persons, our prayers have been answered. -- a Jewish prayer book -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org