On Thu, Apr 4, 2019 at 5:15 AM Tomas Chvatal
Todd Rme píše v St 03. 04. 2019 v 11:57 -0400:
The naming policy from a long time now is that all jupyter-related packages, which pretty much by definition includes ipython-related packages since ipython is part of the jupyter software ecoystem, have used the jupyter_ prefix. This was discussed on the mailing list [1] in 2015 and using this approach was the consensus. Further, since the split it has been the policy that all such packages go into devel:languages:python:jupyter.
Recently there was a move to rename one such package, python-jupyter_ipdb, to just python-ipdb [2], on the grounds that we "we should not rename upstream stuff", and further the new version was pushed into devel:languages:python instead of devel:languages:python:jupyter.
Yeah I should've sent it to :jupyter, my bad there, but easy&quick to amend.
This is a massive change in both python package naming policy and repository polices, which if implemented consistently would require renaming and moving dozens of packages. It would also lead to a lot of ambiguity since whether a package is really an ipython package or a jupyter package is ambiguous and can change over time, which is one reason we don't try to draw the distinction right now.
Considering how many packages this would affect, I would request we discuss it on this mailing list beforehand rather than unilaterally moving and renaming individual packages. I personally think the policies works well, and similar policies are used effectively for a number of other python package families (like django).
[1] https://lists.opensuse.org/opensuse-packaging/2015-08/msg00065.html [2] https://build.opensuse.org/request/show/690081
I actually didn't notice this thread before and I can understand the motivation behind prefixing all the packages as jupyter- for nice namespace, but it has serious drawbacks as I said in the other email.
First, this seems like the sort of thing that should be discussed on the openSUSE python mailing list, or at the very least with the jupyter project maintainer, before changing it. The first I heard that anyone had a problem with the current policy was when I got a delete request for a package. If the consensus is to change it, that is fine, but is the sort of thing that should go through the proper process first, or at the very least be brought to the attention of the person in charge of those packages.
1) differs from upstream
To be pedantic, we do this with most python packages already by adding a python- prefix. We very rarely use the upstream package name verbatim, unlike something like Anaconda. I think thinking about why we do this is worthwhile. At least from my way of thinking about it, it is because these packages are not useful outside of a python context. If you install numpy or django, you aren't going to be able to use it outside of a python interpreter. Python is not just a dependency, these packages will not do anything without being run inside a python interpreter. Putting the python- prefix clearly shows that. 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. Let's take "rise" as an example. Its purpose is to make presentations using Jupyter notebooks. It is useless in a normal python interpreter. It has no user-facing python interface. It has 5 times more javascript code than python code, and the python code it does have is just for installation and loading the javascript code. So I think calling it "python-rise" would be downright misleading, since it really has nothing to do with python. Similarly, "octave_kernel" allows you to run octave code in a jupyter notebook or interpeter. It is written in a mix of python and octave, but that it uses python is an implementation detail. You can't use it from a normal python interpreter. So I think calling it "python-octave_kernel" would be misleading since it has nothing to do with python. 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.
2) differs from other distributions
Again, to be pedantic, distributions all handle python packages differently. Some use the pypi name, some use the egg name, some use the module name, some use python-, others use python2-, etc. openSUSE itself has varied in this regard over time. I am more concerned with making things work well for users.
The above two make it hard for any newcomer to figure out what is the proper name to require, heck I added the ipdb because I was not able to find it.
In my defense, my expectation at the time was that all of these issues were going to be solved in the near future by having automatic python package provides. At the time it was supposed to be just around the corner, but as far as I am aware it never really panned out. -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org