On Wed, Apr 10, 2019 at 8:09 AM Matej Cepl <mcepl@cepl.eu> wrote:
On 2019-04-08, 16:41 GMT, you wrote:
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.
Hmm, there is a problem of consistency: package python-jupyter_calysto comes from the PyPI package calysto, but python-jupyter_highlight_selected_word from the PyPI package jupyter_highlight_selected_word.
I think it would be really better to be consistent, get rid of the superfluous jupyters from the package names and enjoy the compatibility with the rest of packages and ability to use standard packaging tools. I think there is sufficient signal to developers (users are not that important as they will just consume package as dependencies from the main Jupyter package), there is a sufficient signal to developers that package belong to the Jupyter universe by being located in d:l:p:jupyter project.
Yes, as I said later, the consistency issues would need to be fixed.
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.
Looks good.
In terms of python rpm macros, this shouldn't be a huge issue since jupyter-related packages should really be python3-only.
Python macros are useful not only because of Py2k/Py3k dual packaging, I use them even for packages which have %define skip_python2 1 and are thus python3-only.
My point is that there wouldn't need to be any changes to the macros to support this.
So what would need to change is that the pypi update detection script would need to strip both the "python-" and "jupyter-" prefixes.
That would break jupyter_highlight_selected_word.
That would be packaged as "jupyter-jupyter_highlight_selected_word", so it shouldn't break.
Out of curiosity, how does the update detection script deal with command-line applications, or does it?
Badly (patches to https://gitlab.com/mcepl/dlp_check_version_PyPI are more than welcome), we just strip python- part and then have a list of exceptions where we know we should skip the package. Not good.
Overall, I think I spent on the issue jupyter packages more than I want, so bascially do whatever you think is right (and document it).
Okay, fair enough. -- To unsubscribe, e-mail: opensuse-python+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-python+owner@opensuse.org