[opensuse-packaging] package names python-python-*
HI! Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow. Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". This convention is wildly violated. And it makes authors of cross-platform ansible plays, puppet modules, chef receipts, etc. even more miserable. Ciao, Michael.
Hi, On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow. Why get these packages accepted then at all? Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language.
The pypi-name is not necessarily the same as the import-name. E.g. python(3)-dnspython provides the module dns, but is referred to everywhere as dnspython Another example is (python(3)-)python-termstyle. Even on pypi it has the python- prefix (Tough in this example it seems a package without the prefix has been created recently, but there are other examples)
This convention is wildly violated. I see 15 with python-python and 3 with python3-python.
Sebastian A clueless opensuse-newcomer who just started with packaging a few months ago -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow. Why get these packages accepted then at all? Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language.
This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. And what about Python modules never submitted to PyPI e.g. with their own devpi repo? Also I'd strongly object a request to rename package python-ldap to python-python-ldap. IIRC the project name python-ldap (on SF) was chosen by David back in 1998 to have a distinct name on SF and give enough context in the project name on a dev platform not limited to Python.
The pypi-name is not necessarily the same as the import-name.
Yes.
E.g. python(3)-dnspython provides the module dns, but is referred to everywhere as dnspython Another example is (python(3)-)python-termstyle. Even on pypi it has the python- prefix (Tough in this example it seems a package without the prefix has been created recently, but there are other examples)
This convention is wildly violated. I see 15 with python-python and 3 with python3-python.
Of course you can find such exceptions. And people today are causing even greater mess by using already existent module names. Still that's not a good reason to blindly follow that mess. IIRC the Python project itself imposed the package naming rule of "python-<import-name> because at this time (pre-PyPI) the import name-space was considered to be the only unique name-space for modules. AFAICS all distributions follow that rule (with some errornous exceptions of course). Ciao, Michael.
Hi, On 08/13/2016 06:37 PM, Michael Ströder wrote:
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language. This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. Not if Provides and Obsoletes are used? This convention is wildly violated. I see 15 with python-python and 3 with python3-python. Of course you can find such exceptions. Aren't these the wrongly-named packages you referred to in your first mail?
I fully understand your argument and I'm totally fine with changing the naming-conventions to use the import-name. E.g. fedora too has python3-dns, not python3-dnspython. But I'm not the one who decides anything :) Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
Sebastian wrote:
Hi,
On 08/13/2016 06:37 PM, Michael Ströder wrote:
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language. This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. Not if Provides and Obsoletes are used? This convention is wildly violated. I see 15 with python-python and 3 with python3-python. Of course you can find such exceptions. Aren't these the wrongly-named packages you referred to in your first mail?
Nope. Some examples: python-python-gammu imports as gammu python-python-daemon imports as daemon python-python-dateutil imports as dateutil python-python-ipmi imports as ipmi I'm pretty sure I can extend this list but I'm lazy to install the misnamed packages. Ciao, Michael.
On 08/13/2016 07:32 PM, Michael Ströder wrote:
This convention is wildly violated. I see 15 with python-python and 3 with python3-python. Of course you can find such exceptions. Aren't these the wrongly-named packages you referred to in your first mail? Nope.
Some examples: python-python-gammu imports as gammu python-python-daemon imports as daemon python-python-dateutil imports as dateutil python-python-ipmi imports as ipmi
I'm pretty sure I can extend this list but I'm lazy to install the misnamed packages. At least these are (most probably) affected (from devel and factory on OBS):
python3-python3-openid python3-python-axolotl-curve25519 python3-pythonbrew python3-pythondialog python3-python-editor python3-python-gflags python3-python-magic python3-python-memcached python3-python-mimeparse python3-python-openid python3-python-parameters python3-PythonQwt python3-PythonQwtpython-python-axolotl python3-python-social-auth python3-python-sql python3-python-subunit python3-python-termstyle python-python-axolotl python-python-axolotl-curve25519 python-pythonbrew python-python-daemon python-python-dateutil python-python-debianbts python-python-digest python-python-editor python-python-fanart python-python-gammu python-python-gflags python-python-ipmi python-python-jenkins python-python-magic python-python-memcached python-python-mimeparse python-python-openid python-python-parameters python-python-potr python-PythonQwt python-python-snappy python-python-social-auth python-python-spidermonkey python-python-sql python-python-stdnum python-python-subunit python-python-suseapi python-python-termstyle python-python-urljr -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
On Sat, Aug 13, 2016 at 12:37 PM, Michael Ströder <michael@stroeder.com> wrote:
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow. Why get these packages accepted then at all? Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language.
This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. And what about Python modules never submitted to PyPI e.g. with their own devpi repo?
We previously used the import name, but it caused a lot of problems. There are packages that provide multiple imports, multiple packages with the same imports, packages that share imports, packages that install inside the imports of other packages, etc. The pypi package name, however, must be unique, ties in with a lot of automated tools designed to work with pypi, and works with the package names used by the distutils/setuptools requirements specifiers. So the convention was changed to work better with the rest of the python packaging ecosystem, which is focused around pypi package names. What specific automated installation routine that is broken by this policy? Considering that most python packages already use the pypi name for their requirements so they are compatible with tools like pip, and any automated tool would likely need to be able to install packages from pypi, I would be surprised if automated tools were not able to use this information. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Todd Rme wrote:
On Sat, Aug 13, 2016 at 12:37 PM, Michael Ströder <michael@stroeder.com> wrote:
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow. Why get these packages accepted then at all? Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language.
This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. And what about Python modules never submitted to PyPI e.g. with their own devpi repo?
We previously used the import name, but it caused a lot of problems. There are packages that provide multiple imports, multiple packages with the same imports, packages that share imports, packages that install inside the imports of other packages, etc. The pypi package name, however, must be unique, ties in with a lot of automated tools designed to work with pypi, and works with the package names used by the distutils/setuptools requirements specifiers. So the convention was changed to work better with the rest of the python packaging ecosystem, which is focused around pypi package names.
So basically your message boils down to: Forget completely about Python modules shipped with the distribution and better use pip-based installation in virtualenv to avoid relying on random distribution changes to naming conventions. Ok, I will do that and stop updating openSUSE Python modules right now.
What specific automated installation routine that is broken by this policy? Considering that most python packages already use the pypi name for their requirements so they are compatible with tools like pip, and any automated tool would likely need to be able to install packages from pypi, I would be surprised if automated tools were not able to use this information.
See my first posting. Ever heard of DevOps? Ciao, Michael.
On Tue, Aug 16, 2016 at 3:42 AM, Michael Ströder <michael@stroeder.com> wrote:
Todd Rme wrote:
On Sat, Aug 13, 2016 at 12:37 PM, Michael Ströder <michael@stroeder.com> wrote:
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow. Why get these packages accepted then at all? Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language.
This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. And what about Python modules never submitted to PyPI e.g. with their own devpi repo?
We previously used the import name, but it caused a lot of problems. There are packages that provide multiple imports, multiple packages with the same imports, packages that share imports, packages that install inside the imports of other packages, etc. The pypi package name, however, must be unique, ties in with a lot of automated tools designed to work with pypi, and works with the package names used by the distutils/setuptools requirements specifiers. So the convention was changed to work better with the rest of the python packaging ecosystem, which is focused around pypi package names.
So basically your message boils down to: Forget completely about Python modules shipped with the distribution and better use pip-based installation in virtualenv to avoid relying on random distribution changes to naming conventions.
You are talking like there is one uniform naming policy across distros that openSUSE is unilateraly violating. There isn't. For example Debian and openSUSE use "python-foo" for python 2 packages and "python3-foo" for python 3, arch uses "python-foo" for python3 packages and "python3-foo" for python 3 packages, and Fedora uses "python2-foo" for python 2 packages and "python3-foo" for python 3 packages. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Aug 16, 2016 at 11:24 AM, Todd Rme <toddrme2178@gmail.com> wrote:
On Tue, Aug 16, 2016 at 3:42 AM, Michael Ströder <michael@stroeder.com> wrote:
Todd Rme wrote:
On Sat, Aug 13, 2016 at 12:37 PM, Michael Ströder <michael@stroeder.com> wrote:
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow. Why get these packages accepted then at all? Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language.
This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. And what about Python modules never submitted to PyPI e.g. with their own devpi repo?
We previously used the import name, but it caused a lot of problems. There are packages that provide multiple imports, multiple packages with the same imports, packages that share imports, packages that install inside the imports of other packages, etc. The pypi package name, however, must be unique, ties in with a lot of automated tools designed to work with pypi, and works with the package names used by the distutils/setuptools requirements specifiers. So the convention was changed to work better with the rest of the python packaging ecosystem, which is focused around pypi package names.
So basically your message boils down to: Forget completely about Python modules shipped with the distribution and better use pip-based installation in virtualenv to avoid relying on random distribution changes to naming conventions.
You are talking like there is one uniform naming policy across distros that openSUSE is unilateraly violating. There isn't. For example Debian and openSUSE use "python-foo" for python 2 packages and "python3-foo" for python 3, arch uses "python-foo" for python3 packages and "python3-foo" for python 3 packages, and Fedora uses "python2-foo" for python 2 packages and "python3-foo" for python 3 packages.
Sorry, typo. arch uses "python2-foo" for python 2 packages. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Aug 16, 2016 at 11:24 AM, Todd Rme <toddrme2178@gmail.com> wrote:
Todd Rme wrote:
Sebastian wrote:
On 08/13/2016 10:33 AM, Michael Ströder wrote: > Any reason why so many Python module packages have the misnomer python-python-* > as package names? And the set of this misnomers even grow. Why get these packages accepted then at all? > Since ages the convention is that a distribution package name > of a Python module should be "python-<import-name>". The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy > All Python module packages, whether pure Python or C-based, should be called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software repository for the Python programming language. This strange SUSE-specific rule is IMO non-sense and will cause nothing than grief. Renaming existing packages will break *lots* of existing (automated) installation routines. And what about Python modules never submitted to PyPI e.g. with their own devpi repo? We previously used the import name, but it caused a lot of problems. There are packages that provide multiple imports, multiple packages with the same imports, packages that share imports, packages that install inside the imports of other packages, etc. The pypi package name, however, must be unique, ties in with a lot of automated tools designed to work with pypi, and works with the package names used by
On Sat, Aug 13, 2016 at 12:37 PM, Michael Ströder <michael@stroeder.com> wrote: the distutils/setuptools requirements specifiers. So the convention was changed to work better with the rest of the python packaging ecosystem, which is focused around pypi package names. So basically your message boils down to: Forget completely about Python modules shipped with the distribution and better use pip-based installation in virtualenv to avoid relying on random distribution changes to naming conventions. You are talking like there is one uniform naming policy across distros
On Tue, Aug 16, 2016 at 3:42 AM, Michael Ströder <michael@stroeder.com> wrote: that openSUSE is unilateraly violating. There isn't. For example Debian and openSUSE use "python-foo" for python 2 packages and "python3-foo" for python 3, arch uses "python-foo" for python3 packages and "python3-foo" for python 3 packages, and Fedora uses "python2-foo" for python 2 packages and "python3-foo" for python 3 packages. Sorry, typo. arch uses "python2-foo" for python 2 packages. There are also obscure names apart from the prefix: Ubuntu has python3-tz which packages the module pytz. import und pypi name are pytz. But on the other hand, they have python3-pymongo and
On 08/16/2016 05:31 PM, Todd Rme wrote: python3-dnspython (import name dns). EPEL 6 even has pymongo by itself.
Todd Rme wrote:
You are talking like there is one uniform naming policy across distros that openSUSE is unilateraly violating. There isn't.
If you're using your favourite search engine you will see within seconds that you don't have to teach me about the differences of various Linux distros. I already deal with that in lots of cases. But I also know the limits and the enormous effort. Especially if you start renaming lots of packages on a platform you break lots existing configuration management. Michael Matz wrote:
But another thing is also true: installation routines that rely on package names are inherently flawed, there are all sorts of reasons to rename packages
Which is a pretty big F*** Y** to all DevOps coders out there. I also wonder what SLES product managers will say about this (if you dare to really explain the details to them). I give up here and will take another route. Goodbye. Ciao, Michael.
On Mittwoch, 17. August 2016 00:50:49 Michael Ströder wrote:
Michael Matz wrote:
But another thing is also true: installation routines that rely on package names are inherently flawed, there are all sorts of reasons to rename packages
Which is a pretty big F*** Y** to all DevOps coders out there. I also wonder what SLES product managers will say about this (if you dare to really explain the details to them).
Michael, while I have some compassion for your anger, you missed to point out, in which way this naming scheme results in a SNAFU for you. I've given the example of python-python-daemon in another thread. Sure, not a beauty, but how would you reference the PyPI package "python-daemon", given that many other variants including "daemon" are different packages. The import name isn't unique and hence, you cannot reference specific packages based on it. Even searching would be a problem. Thanks, Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Aug 16, 2016 at 6:50 PM, Michael Ströder <michael@stroeder.com> wrote:
Todd Rme wrote:
You are talking like there is one uniform naming policy across distros that openSUSE is unilateraly violating. There isn't.
If you're using your favourite search engine you will see within seconds that you don't have to teach me about the differences of various Linux distros. I already deal with that in lots of cases. But I also know the limits and the enormous effort.
Especially if you start renaming lots of packages on a platform you break lots existing configuration management.
First, you are talking like this is some sudden change we just sprung on you. This has been the policy for four years. What you are asking us to do is revert a long-standing policy and change dozens, if not hundreds, of package names, break all of our tools, and take us out of line with the rest of the python software community, just to avoid fixing the names of a couple of packages that haven't been brought in line with this policy yet. And you are asking us to do all this to fix a problem that is probably not even going to be an issue much longer since distros seem to be converging on an automatic way to handle provides. Second, you are acting like openSUSE is some exceptionally terrible group for changing our naming conventions. But Arch changed their policy around the same time we did in a much larger way than us (changed the names of all their python packages), and Fedora changed their policy in a larger way than us just a couple months ago (changing the names of all of their python 2 packages). But I don't see you on those mailing lists demanding they reverse their existing policies and change all of their package names back to what they were before. So what is so exceptionally bad about openSUSE's change compared to other changes over the last 5 years or so that we and we alone need to change a huge number of package names to something else? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Wed, 17 Aug 2016, Michael Ströder wrote:
Michael Matz wrote:
But another thing is also true: installation routines that rely on package names are inherently flawed, there are all sorts of reasons to rename packages
Which is a pretty big F*** Y** to all DevOps coders out there.
No, it's simply stating the truth. It always has been a bad idea to rely on package names, and always will be. If that's news to all DevOps coders (I don't know, but am surprised by that) then their thinking is the problem. But to be honest I don't see the problem: If somebody is a coder and is able to retrieve packages by name, then it's trivial to add a layer of indirection and instead refer to them by a Provide (or similar concept for the other packaging system).
I also wonder what SLES product managers will say about this (if you dare to really explain the details to them).
I happen to know that they agree with me. We had customers who relied on package names in their installation routines. We eventually managed to explain to them that that's a bad idea.
I give up here and will take another route. Goodbye.
As you wish. Ciao, Michael.
On Samstag, 13. August 2016 17:46:30 Sebastian wrote:
Hi,
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Why get these packages accepted then at all?
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>".
The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software
This rule is actively enforced from a couple of SuSE people, that didn't accept a submission to d:l:py with a differing name, namely Sascha Peilicke. While I don't like the scheme much, it also has upsides: you can both search on PyPI and py2pack is able to locate and fetch the package unambiguously, with the name derived from the spec name (omitting python-). In that light, speaking of violating some arbitrary naming scheme is invidious. IOW, which naming scheme do we have to follow tomorrow? Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hans-Peter Jansen wrote:
On Samstag, 13. August 2016 17:46:30 Sebastian wrote:
Hi,
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Why get these packages accepted then at all?
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>".
The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software
This rule is actively enforced from a couple of SuSE people, that didn't accept a submission to d:l:py with a differing name, namely Sascha Peilicke.
Where and when was this discussed *before* enforcing this weird naming convention? Ciao, Michael.
Dear Michael, On Dienstag, 16. August 2016 09:45:32 Michael Ströder wrote:
Hans-Peter Jansen wrote:
On Samstag, 13. August 2016 17:46:30 Sebastian wrote:
Hi,
On 08/13/2016 10:33 AM, Michael Ströder wrote:
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Why get these packages accepted then at all?
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>".
The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software
This rule is actively enforced from a couple of SuSE people, that didn't accept a submission to d:l:py with a differing name, namely Sascha Peilicke. Where and when was this discussed *before* enforcing this weird naming convention?
From an external contributor perspective with the intention of submitting a considerable amount of packages, you try to avoid upsetting those, that are
I didn't follow the public discussions closely, I'm just a contributor of a couple of packages. Around 2014, some packages were declined, similar to the one attached. Thought, I had some discussion about this, but cannot find it right now. I was under the impression, this was decided in some internal discussion, and then enforced with the reasoning from above. the primary decision makers of your work later on... Probably, the wiki has some blame tool, that helps to identify the person, who wrote the main part of the Naming policy section. Might be more fruitful to ask that person, although I have a strong suspicion, who that is. Sascha did the most work in that area at that time, and is the Author of the still helpful tool py2pack (even it takes some manual intervention to properly generate the spec from time to time...) Funnily, I have this item on my todo list: port py2pack over to python3 Cheers, Pete
On 08/16/2016 06:22 PM, Hans-Peter Jansen wrote:
As the module seems to be called "python-future", as per the Python pkg policy and to not confuse it with python-futures, please rename to "python-python-future". TIA!
python-pypi- makes far more sense then python-python- if what you are trying to achieve is distinguishing between modules that are built into the language and ones that are shipped from a 3rd party via pypi, either way that will still break lots of things for lots of people. (Speaking from somone who maintains python bindings for the third largest independent gui toolkit shipped with openSUSE and several desktop applications that use said toolkit. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Dienstag, 16. August 2016 18:38:04 Simon Lees wrote:
As the module seems to be called "python-future", as per the Python pkg policy and to not confuse it with python-futures, please rename to "python-python-future". TIA!
On 08/16/2016 06:22 PM, Hans-Peter Jansen wrote: python-pypi- makes far more sense then python-python- if what you are trying to achieve is distinguishing between modules that are built into the language and ones that are shipped from a 3rd party via pypi, either way that will still break lots of things for lots of people. (Speaking from somone who maintains python bindings for the third largest independent gui toolkit shipped with openSUSE and several desktop applications that use said toolkit.
Just to clarify: python package naming convention is: python{,3}-%{pypi-name} when the pypi name happens to start with python, it results in e.g.: python-python-daemon or do you suggest python-pypi-python-daemon which is even uglier. Note that python-pypi-daemon would reference a different package, given you want "python-daemon" specifically: https://pypi.python.org/pypi?%3Aaction=search&term=daemon&submit=search Pete -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/18/2016 01:03 AM, Hans-Peter Jansen wrote:
On Dienstag, 16. August 2016 18:38:04 Simon Lees wrote:
As the module seems to be called "python-future", as per the Python pkg policy and to not confuse it with python-futures, please rename to "python-python-future". TIA!
On 08/16/2016 06:22 PM, Hans-Peter Jansen wrote: python-pypi- makes far more sense then python-python- if what you are trying to achieve is distinguishing between modules that are built into the language and ones that are shipped from a 3rd party via pypi, either way that will still break lots of things for lots of people. (Speaking from somone who maintains python bindings for the third largest independent gui toolkit shipped with openSUSE and several desktop applications that use said toolkit.
Just to clarify: python package naming convention is:
python{,3}-%{pypi-name}
when the pypi name happens to start with python, it results in e.g.:
python-python-daemon
Yeah so in this case I was suggesting modifying the policy such that when the pypi name happens to start with python then one of the python-'s is dropped.
or do you suggest
python-pypi-python-daemon
I was suggesting python-pypi-daemon, in the case that my above suggestion really wasn't liked by someone or there was a conflict. I guess if the package "daemon" and the package "python-daemon" both existed in pypi the most logical naming would be to have a python-daemon package and a python-python-daemon package, and yes I guess thats slightly silly and confusing but its only following on upstreams sillyness and confusion in that case. But I think if only the package "daemon" exists or only the package "python-daemon" exists in both cases the name of the openSUSE package should be python-daemon, searching pypi your clearly going to find the right package that way.
which is even uglier. Note that python-pypi-daemon would reference a different package, given you want "python-daemon" specifically:
https://pypi.python.org/pypi?%3Aaction=search&term=daemon&submit=search
Pete
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, 2016-08-18 at 09:17 +0930, Simon Lees wrote:
I was suggesting python-pypi-daemon, in the case that my above suggestion really wasn't liked by someone or there was a conflict. I guess if the package "daemon" and the package "python-daemon" both existed in pypi the most logical naming would be to have a python- daemon package and a python-python-daemon package, and yes I guess thats slightly silly and confusing but its only following on upstreams sillyness and confusion in that case. But I think if only the package "daemon" exists or only the package "python-daemon" exists in both cases the name of the openSUSE package should be python-daemon, searching pypi your clearly going to find the right package that way.
I don't think it's pracical to have a naming policy that changes the outcome 'depending on what else is there on pypi' - especially as this content can change. Just imagine day 'x', I go to package the 'currently existing' python- FOO from pypi - there is no FOO yet on pypi, so according to your rasoning, I am calling my package python-FOO. On day 'x+1', FOO appears on pypi... what now? The correct approach is what is currently happening in RPM[0]: automatic provides for python modules, similar to what is already done for Perl and Ruby... then the package name is quite irrelevant, as dependencies should not be expressed by the package name, but the actual 'module' one wants to load. Cheers, Dominique [0] http://www.rpm.org/ticket/154
On 08/16/2016 10:52 AM, Hans-Peter Jansen wrote:
Sascha did the most work in that area at that time, and is the Author of the still helpful tool py2pack (even it takes some manual intervention to properly generate the spec from time to time...)
Funnily, I have this item on my todo list: port py2pack over to python3 It's only about the template, there's already a python3-py2pack Have a look here: https://github.com/saschpe/py2pack/issues/59
Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
On 08/16/2016 10:52 AM, Hans-Peter Jansen wrote
Sascha did the most work in that area at that time, and is the Author of the still helpful tool py2pack (even it takes some manual intervention to properly generate the spec from time to time...)
Funnily, I have this item on my todo list: port py2pack over to python3 It's only about the template, there's already a python3-py2pack Have a look here: https://github.com/saschpe/py2pack/issues/59
Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
Hi, On Tue, 16 Aug 2016, Michael Ströder wrote:
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>".
The wiki says: https://en.opensuse.org/openSUSE:Packaging_Python#Naming_policy
All Python module packages, whether pure Python or C-based, should be
called python-modulename. modulename should be the name of this module on the Python Package Index, the official third-party software
This rule is actively enforced from a couple of SuSE people, that didn't accept a submission to d:l:py with a differing name, namely Sascha Peilicke.
Where and when was this discussed *before* enforcing this weird naming convention?
I guess you can discuss it now publicly. Sascha isn't with SUSE anymore, and it's not clear if anybody remembers the full reasons for that policy. FWIW: the thing the policy wants to achieve (at least that which I gather from this thread, I'm not involved or interested in python packages per se), namely having a relieable naming for python modules coming from the pypi eco-system could have been achieved just as well by enforcing the existence of one additional Provides: named funnily. No package rename (or naming policy) would have been necessary. But another thing is also true: installation routines that rely on package names are inherently flawed, there are all sorts of reasons to rename packages (and some of them are more necessary than this example here), and of course package names often differ cross distributions, while Provides are more stable or can be made so (because there can be multiple per package). So this incident also presents opportunities to fix those not well thought out installation schemes. Ciao, Michael.
On Sat, Aug 13, 2016 at 10:33:00AM +0200, Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
As mentioned in other answers, the rule is to use python-<pypi-name> as package name. And we use that rule to convert pip requirements (which refer to the pypi name and are often given from te requirements.txt file or the setup.cfg file) to rpm package names. That would be impossible when you use python-<import-name>. Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thomas Bechtold wrote:
On Sat, Aug 13, 2016 at 10:33:00AM +0200, Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
As mentioned in other answers, the rule is to use python-<pypi-name> as package name. And we use that rule to convert pip requirements (which refer to the pypi name and are often given from te requirements.txt file or the setup.cfg file) to rpm package names. That would be impossible when you use python-<import-name>.
Changing names of existing packages without resolving a real issue for that package breaks installation code. It boils down to avoid using distribution packages. Ciao, Michael.
Hi, On Tue, Aug 16, 2016 at 09:44:18AM +0200, Michael Ströder wrote:
Thomas Bechtold wrote:
On Sat, Aug 13, 2016 at 10:33:00AM +0200, Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
As mentioned in other answers, the rule is to use python-<pypi-name> as package name. And we use that rule to convert pip requirements (which refer to the pypi name and are often given from te requirements.txt file or the setup.cfg file) to rpm package names. That would be impossible when you use python-<import-name>.
Changing names of existing packages without resolving a real issue for that package breaks installation code. It boils down to avoid using distribution packages.
Can you give a concrete example where it breaks something? At least I tried to follow [1] and added the Provides/Obsoletes when I renamed a package so the dependencies should still be resolvable. Best, Tom [1] https://en.opensuse.org/openSUSE:Package_dependencies#Renaming_a_package -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Thomas Bechtold wrote:
On Tue, Aug 16, 2016 at 09:44:18AM +0200, Michael Ströder wrote:
Thomas Bechtold wrote:
On Sat, Aug 13, 2016 at 10:33:00AM +0200, Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
As mentioned in other answers, the rule is to use python-<pypi-name> as package name. And we use that rule to convert pip requirements (which refer to the pypi name and are often given from te requirements.txt file or the setup.cfg file) to rpm package names. That would be impossible when you use python-<import-name>.
Changing names of existing packages without resolving a real issue for that package breaks installation code. It boils down to avoid using distribution packages.
Can you give a concrete example where it breaks something? At least I tried to follow [1] and added the Provides/Obsoletes when I renamed a package so the dependencies should still be resolvable.
What all distro packagers most times ignore: There is a world *outside* the distribution with *lots* of configuration code or written operational manuals which all *break* with package renaming. And even I'd be eager and willing to spend the time to write version-specific configuration code openSUSE does not provide any robust way to determine the particular version. As I was told here there's not even a robust way to determine the URL for additional version-specific repos. So what's especially frustrating for me is: Some people just change a naming convention at their own discretion without discussing this in public and without even considering the impact this has for others. Up to now I used openSUSE because there's was a good way to get new upstream code into packages pretty quickly. But if I'm now forced to pip-based installation in virtualenv there's absolutely no point to use openSUSE for my projects anymore. Ciao, Michael.
Michael Ströder schrieb:
[...] So what's especially frustrating for me is: Some people just change a naming convention at their own discretion without discussing this in public and without even considering the impact this has for others.
That's a baseless accusation. The naming was discussed on this list in 2011: https://lists.opensuse.org/opensuse-packaging/2011-05/msg00186.html What's still missing seems to be an automatic Provides: python(importname) for python packages. As others have pointed out the package name is rather fragile to rely on. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Aug 16, 2016 at 9:59 AM, Ludwig Nussel <ludwig.nussel@suse.de> wrote:
Michael Ströder schrieb:
[...] So what's especially frustrating for me is: Some people just change a naming convention at their own discretion without discussing this in public and without even considering the impact this has for others.
That's a baseless accusation. The naming was discussed on this list in 2011: https://lists.opensuse.org/opensuse-packaging/2011-05/msg00186.html
What's still missing seems to be an automatic Provides: python(importname) for python packages. As others have pointed out the package name is rather fragile to rely on.
That sounds like a much better solution to me. It also works with packages that provide multiple imports. However, it still breaks in some cases, such as where multiple packages put files in the same import (like many of the "backports" packages do). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Aug 16, 2016 at 4:52 AM, Michael Ströder <michael@stroeder.com> wrote:
Thomas Bechtold wrote:
On Tue, Aug 16, 2016 at 09:44:18AM +0200, Michael Ströder wrote:
Thomas Bechtold wrote:
On Sat, Aug 13, 2016 at 10:33:00AM +0200, Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
As mentioned in other answers, the rule is to use python-<pypi-name> as package name. And we use that rule to convert pip requirements (which refer to the pypi name and are often given from te requirements.txt file or the setup.cfg file) to rpm package names. That would be impossible when you use python-<import-name>.
Changing names of existing packages without resolving a real issue for that package breaks installation code. It boils down to avoid using distribution packages.
Can you give a concrete example where it breaks something? At least I tried to follow [1] and added the Provides/Obsoletes when I renamed a package so the dependencies should still be resolvable.
What all distro packagers most times ignore: There is a world *outside* the distribution with *lots* of configuration code or written operational manuals which all *break* with package renaming.
That is exactly what openSUSE is avoiding by following the same conventions as the rest of the python software ecosystem. These are python packages, so I don't understand why you are so opposed to using standard python conventions for those packages. The python software community has unified around pypi. Some distros have not kept up with that. openSUSE has. That makes it much easier for openSUSE to work with python-oriented tools. If you really have that big a problem with it we could make it so python packages Provide the module name as well. But I don't think changing the naming policy to make us LESS compatible with the world outside our distro is a good idea. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Michael, On Tue, Aug 16, 2016 at 10:52:00AM +0200, Michael Ströder wrote:
Thomas Bechtold wrote:
On Tue, Aug 16, 2016 at 09:44:18AM +0200, Michael Ströder wrote:
Thomas Bechtold wrote:
On Sat, Aug 13, 2016 at 10:33:00AM +0200, Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
As mentioned in other answers, the rule is to use python-<pypi-name> as package name. And we use that rule to convert pip requirements (which refer to the pypi name and are often given from te requirements.txt file or the setup.cfg file) to rpm package names. That would be impossible when you use python-<import-name>.
Changing names of existing packages without resolving a real issue for that package breaks installation code. It boils down to avoid using distribution packages.
Can you give a concrete example where it breaks something? At least I tried to follow [1] and added the Provides/Obsoletes when I renamed a package so the dependencies should still be resolvable.
What all distro packagers most times ignore: There is a world *outside* the distribution with *lots* of configuration code or written operational manuals which all *break* with package renaming.
What exactly breaks? For i.e. python-python-dateutil from Tumbleweed I can: 1) Search the package with "zypper se python-dateutil" 2) Installing the package with "zypper in python-dateutil" 3) Find out which package provides python-dateutil with "zypper wp python-dateutil"
And even I'd be eager and willing to spend the time to write version-specific configuration code openSUSE does not provide any robust way to determine the particular version. As I was told here there's not even a robust way to determine the URL for additional version-specific repos.
So what's especially frustrating for me is: Some people just change a naming convention at their own discretion without discussing this in public and without even considering the impact this has for others.
Up to now I used openSUSE because there's was a good way to get new upstream code into packages pretty quickly. But if I'm now forced to pip-based installation in virtualenv there's absolutely no point to use openSUSE for my projects anymore.
Why are you forced todo pip based installations now? Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/16/2016 03:49 PM, Thomas Bechtold wrote:
On Sat, Aug 13, 2016 at 10:33:00AM +0200, Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
As mentioned in other answers, the rule is to use python-<pypi-name> as package name. And we use that rule to convert pip requirements (which refer to the pypi name and are often given from te requirements.txt file or the setup.cfg file) to rpm package names. That would be impossible when you use python-<import-name>.
Best,
Tom
Couldn't the rule simply be changed to omit the second python- if it matches exactly (including case), starting everything with python-python- is one of the sillier ideas ive heard of in recent time (from a users perspective who 99% of the time looks in the distro repo and doesn't touch pip or whatever it is. I believe Michael is talking about working with automated install scripts / documentation / spec files or anything else designed to work across distro's (if you convince redhat and debian packagers to follow the follow similar python-python- conventions you would have an argument). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Simon Lees wrote:
I believe Michael is talking about working with automated install scripts / documentation / spec files or anything else designed to work across distro's
Or just work across different versions of SUSE distros.
(if you convince redhat and debian packagers to follow the follow similar python-python- conventions you would have an argument).
If you consider the typical customers of Enterprise distros that's a complete no-go! Ciao, Michael.
On 08/16/2016 06:24 PM, Michael Ströder wrote:
Simon Lees wrote:
I believe Michael is talking about working with automated install scripts / documentation / spec files or anything else designed to work across distro's
Or just work across different versions of SUSE distros.
(if you convince redhat and debian packagers to follow the follow similar python-python- conventions you would have an argument).
If you consider the typical customers of Enterprise distros that's a complete no-go!
Ciao, Michael.
Well I put it this way because i'm sure if someone were able to convince both debian and Red Hat to break everything by changing to python-python- they must have an exceptionally compelling argument :) as personally I doubt they would adopt this. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adeliade Australia, UTC+9:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On samedi, 13 août 2016 10.33:00 h CEST Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". This convention is wildly violated. And it makes authors of cross-platform ansible plays, puppet modules, chef receipts, etc. even more miserable.
Ciao, Michael.
After reading the whole thread, I would like to try to summarize it a bit so we can decide as a community how we can move forward. 1) We have a tool python-py2pac and almost python3-py2pac https://github.com/saschpe/py2pack https://github.com/saschpe/py2pack/issues/59 As Sacha is not that more active in our packaging community, I would tend to believe it would be cool to have 1.a : A brave maintainer of d:l:p / d:l:p3 fork it, see how it can be improved and propose it as a tool inside https://github.com/openSUSE So it become a tool for everybody 1.b : Point to that tool location inside our Python(3) wiki page 2) Michael remark about python-python-* I remember myself being refused on sr with python3-dateutils :-) I'm using a lot of system require for any python's stuff deployed here. I didn't see a python module not being able to use those system deployed. But I've not a overlong list of requires, and moreover all of are python3. 2.a Michael if you have a list of precise packages that failed to fullfill those provides/requires could you create a list ? Would be really useful to get it writen down in bugzilla and bring back the number here, or in worse case, bring the list here. I will try to then create that bug. 3) Python / Python3 : How to fix our mess, and create a bright future. If packaging can be fun, the inverse can be true. I believe we are the last community that package python 2 et python 3 version in a separate way. This has already cause some grief, and we really need to fix it, no? I've already heard that there's reasons behind the choice made. But we lack the fundamentals, as they are not clearly explained on obs project's page, nor in the wiki. So if new comer, like me arrived and try to understand how it works, you spend too much time on guessing and SR try and errors. With the py2/py3 split, we also tend to forget to update one or the other repository (py2pack need to be fixed and improved to handle that), and we also have constants divergences between the 2 specs, which will increase errors, lost tracking bugs, or have version specific bugs. This will (or did it already) kill any efforts to bring new hands to help. Ease our live (packager, users, bugfix & so on), and also get a coherent eco- system around python technology. 3.a What about opening a real discussion about our Python situation - Be it here on packaging list with a simple [python] prefix in the subject - Be it on a discussion page in the wiki (if editing is now fixed) - Be it (creative minds your input here) * I'm really interested by feedback or thoughput of SUSE's employee in charge of LTS support. More we will work together, better the solution will be. 3.b Prepare a kind of RFC for Python at openSUSE - Publish (even on news) and explain where comments should goes, so we can track and pick the good ideas - Organize obs structure to handle the changes (hello obs guru) - Put the changes in action (Hey why not then a pyckaton for that stuff?) We don't need a super-heros here, I'm more confident in the fact that a team that want to achieve a collective forward can make it better than any individual effort. 4) Any stuff I've forget Because I'm too new in python world, I've certainly forget things. Be this paragraph yours. Hope this message, can help our collective effort to make openSUSE the greatest choice OS. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi, On Tue, Aug 16, 2016 at 12:00:43PM +0200, Bruno Friedmann wrote:
On samedi, 13 août 2016 10.33:00 h CEST Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". This convention is wildly violated. And it makes authors of cross-platform ansible plays, puppet modules, chef receipts, etc. even more miserable.
Ciao, Michael.
After reading the whole thread, I would like to try to summarize it a bit so we can decide as a community how we can move forward.
1) We have a tool python-py2pac and almost python3-py2pac https://github.com/saschpe/py2pack https://github.com/saschpe/py2pack/issues/59
I basically took over maintainership for py2pack and did some improvements in the past (see i.e. https://toabctl.wordpress.com/2016/07/03/improved-python-packaging-for-opens... ). I already talked to Sascha and he's fine with moving py2pack to the openSUSE github namespace. Is there a process to request this? Or should I just move it and update the wiki and the documentation? Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/16/2016 12:37 PM, Thomas Bechtold wrote:
Hi,
On Tue, Aug 16, 2016 at 12:00:43PM +0200, Bruno Friedmann wrote:
On samedi, 13 août 2016 10.33:00 h CEST Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". This convention is wildly violated. And it makes authors of cross-platform ansible plays, puppet modules, chef receipts, etc. even more miserable.
Ciao, Michael.
After reading the whole thread, I would like to try to summarize it a bit so we can decide as a community how we can move forward.
1) We have a tool python-py2pac and almost python3-py2pac https://github.com/saschpe/py2pack https://github.com/saschpe/py2pack/issues/59
I basically took over maintainership for py2pack and did some improvements in the past (see i.e. https://toabctl.wordpress.com/2016/07/03/improved-python-packaging-for-opens... ). I already talked to Sascha and he's fine with moving py2pack to the openSUSE github namespace. Is there a process to request this? Or should I just move it and update the wiki and the documentation?
Yes, just move it and update the wiki and docs. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Public Cloud Architect LINUX rjschwei@suse.com IRC: robjo -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Aug 16, 2016 at 02:57:53PM -0400, Robert Schweikert wrote:
On 08/16/2016 12:37 PM, Thomas Bechtold wrote:
Hi,
On Tue, Aug 16, 2016 at 12:00:43PM +0200, Bruno Friedmann wrote:
On samedi, 13 août 2016 10.33:00 h CEST Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". This convention is wildly violated. And it makes authors of cross-platform ansible plays, puppet modules, chef receipts, etc. even more miserable.
Ciao, Michael.
After reading the whole thread, I would like to try to summarize it a bit so we can decide as a community how we can move forward.
1) We have a tool python-py2pac and almost python3-py2pac https://github.com/saschpe/py2pack https://github.com/saschpe/py2pack/issues/59
I basically took over maintainership for py2pack and did some improvements in the past (see i.e. https://toabctl.wordpress.com/2016/07/03/improved-python-packaging-for-opens... ). I already talked to Sascha and he's fine with moving py2pack to the openSUSE github namespace. Is there a process to request this? Or should I just move it and update the wiki and the documentation?
Yes, just move it and update the wiki and docs.
Done. It's now at https://github.com/openSUSE/py2pack .But how do I get admin rights for that repository? I would like to create labels and maybe milestones. Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On jeudi, 18 août 2016 10.36:56 h CEST Thomas Bechtold wrote:
On Tue, Aug 16, 2016 at 02:57:53PM -0400, Robert Schweikert wrote:
On 08/16/2016 12:37 PM, Thomas Bechtold wrote:
Hi,
On Tue, Aug 16, 2016 at 12:00:43PM +0200, Bruno Friedmann wrote:
On samedi, 13 août 2016 10.33:00 h CEST Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". This convention is wildly violated. And it makes authors of cross-platform ansible plays, puppet modules, chef receipts, etc. even more miserable.
Ciao, Michael.
After reading the whole thread, I would like to try to summarize it a bit so we can decide as a community how we can move forward.
1) We have a tool python-py2pac and almost python3-py2pac https://github.com/saschpe/py2pack https://github.com/saschpe/py2pack/issues/59
I basically took over maintainership for py2pack and did some improvements in the past (see i.e. https://toabctl.wordpress.com/2016/07/03/improved-python-packaging-for-> > > opensuse/ ). I already talked to Sascha and he's fine with moving py2pack to the openSUSE github namespace. Is there a process to request this? Or should I just move it and update the wiki and the documentation?
Yes, just move it and update the wiki and docs.
Done. It's now at https://github.com/openSUSE/py2pack .But how do I get admin rights for that repository? I would like to create labels and maybe milestones.
Best,
Tom Hey Tom, great step, thanks for your efforts. Very appreciate.
You normally ask owner of openSUSE to be part the rw user of py2pack on github. Was so long time, that I can't remember the exactly how but here one of the pointer. Normally there's a team dedicated for a repository, and then you can ask to join the team https://github.com/orgs/openSUSE/teams In the case of a new repository, I don't know how to create the team and setup the rights. perhaps a email to admins(at)opensuse(dot)org ? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 19, 2016 at 10:09:12AM +0200, Bruno Friedmann wrote:
On jeudi, 18 août 2016 10.36:56 h CEST Thomas Bechtold wrote:
On Tue, Aug 16, 2016 at 02:57:53PM -0400, Robert Schweikert wrote:
On 08/16/2016 12:37 PM, Thomas Bechtold wrote:
Hi,
On Tue, Aug 16, 2016 at 12:00:43PM +0200, Bruno Friedmann wrote:
On samedi, 13 août 2016 10.33:00 h CEST Michael Ströder wrote:
HI!
Any reason why so many Python module packages have the misnomer python-python-* as package names? And the set of this misnomers even grow.
Since ages the convention is that a distribution package name of a Python module should be "python-<import-name>". This convention is wildly violated. And it makes authors of cross-platform ansible plays, puppet modules, chef receipts, etc. even more miserable.
Ciao, Michael.
After reading the whole thread, I would like to try to summarize it a bit so we can decide as a community how we can move forward.
1) We have a tool python-py2pac and almost python3-py2pac https://github.com/saschpe/py2pack https://github.com/saschpe/py2pack/issues/59
I basically took over maintainership for py2pack and did some improvements in the past (see i.e. https://toabctl.wordpress.com/2016/07/03/improved-python-packaging-for-> > > opensuse/ ). I already talked to Sascha and he's fine with moving py2pack to the openSUSE github namespace. Is there a process to request this? Or should I just move it and update the wiki and the documentation?
Yes, just move it and update the wiki and docs.
Done. It's now at https://github.com/openSUSE/py2pack .But how do I get admin rights for that repository? I would like to create labels and maybe milestones.
Best,
Tom Hey Tom, great step, thanks for your efforts. Very appreciate.
You normally ask owner of openSUSE to be part the rw user of py2pack on github. Was so long time, that I can't remember the exactly how but here one of the pointer. Normally there's a team dedicated for a repository, and then you can ask to join the team https://github.com/orgs/openSUSE/teams
In the case of a new repository, I don't know how to create the team and setup the rights.
I was able to create a new team (python-packaging, see https://github.com/orgs/openSUSE/teams/python-packaging ).
perhaps a email to admins(at)opensuse(dot)org ?
Done to give the new team admin rights for the py2pack repo. Thanks for the help! Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Done to give the new team admin rights for the py2pack repo.
Thanks for the help! Best, Tom
Excellent, so I will be able to open an issue about the bad name :-) I mean pypi2spec would be a more auto-suffisant name explaining by itself what is does no ? py2pack could be a python2 compressing engine afterall :-)) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Fri, Aug 19, 2016 at 04:43:26PM +0200, Bruno Friedmann wrote:
Done to give the new team admin rights for the py2pack repo.
Thanks for the help! Best, Tom
Excellent, so I will be able to open an issue about the bad name :-)
I mean pypi2spec would be a more auto-suffisant name explaining by itself what is does no ?
No. It can generate from any sdist tarball a rpm package. It's not tied to pypi. Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/19/2016 08:43 AM, Bruno Friedmann wrote:
Done to give the new team admin rights for the py2pack repo.
Thanks for the help! Best, Tom
Excellent, so I will be able to open an issue about the bad name :-)
I mean pypi2spec would be a more auto-suffisant name explaining by itself what is does no ?
py2pack could be a python2 compressing engine afterall :-))
I think it should be called "python-py2pack"... (ducks) -- Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On 08/19/2016 09:11 PM, Jason Craig wrote:
On 08/19/2016 08:43 AM, Bruno Friedmann wrote:
Done to give the new team admin rights for the py2pack repo.
Thanks for the help! Best, Tom
Excellent, so I will be able to open an issue about the bad name :-)
I mean pypi2spec would be a more auto-suffisant name explaining by itself what is does no ?
py2pack could be a python2 compressing engine afterall :-))
I think it should be called "python-py2pack"... It is: https://software.opensuse.org/package/python-py2pack https://software.opensuse.org/package/python3-py2pack
-- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
Hi, On 08/16/2016 12:00 PM, Bruno Friedmann wrote:
3) Python / Python3 : How to fix our mess, and create a bright future.
If packaging can be fun, the inverse can be true. I believe we are the last community that package python 2 et python 3 version in a separate way. This has already cause some grief, and we really need to fix it, no?
I've already heard that there's reasons behind the choice made. But we lack the fundamentals, as they are not clearly explained on obs project's page, nor in the wiki. So if new comer, like me arrived and try to understand how it works, you spend too much time on guessing and SR try and errors.
With the py2/py3 split, we also tend to forget to update one or the other repository (py2pack need to be fixed and improved to handle that), and we also have constants divergences between the 2 specs, which will increase errors, lost tracking bugs, or have version specific bugs.
This will (or did it already) kill any efforts to bring new hands to help. Ease our live (packager, users, bugfix & so on), and also get a coherent eco- system around python technology.
3.a What about opening a real discussion about our Python situation - Be it here on packaging list with a simple [python] prefix in the subject - Be it on a discussion page in the wiki (if editing is now fixed) - Be it (creative minds your input here) * I'm really interested by feedback or thoughput of SUSE's employee in charge of LTS support. More we will work together, better the solution will be.
3.b Prepare a kind of RFC for Python at openSUSE - Publish (even on news) and explain where comments should goes, so we can track and pick the good ideas - Organize obs structure to handle the changes (hello obs guru) - Put the changes in action (Hey why not then a pyckaton for that stuff?)
We don't need a super-heros here, I'm more confident in the fact that a team that want to achieve a collective forward can make it better than any individual effort. Unfortunately, there haven't been any comments on this section. But I'd too like to see improvements here.
* The py2/py3 split for devel-projects and thus all packages is very annoying IMHO. Supporting two packages per specfile would decrease the effort. But is this actually possible with OBS currently? I personally only support py 3 for any new packages I want to package and push to openSUSE, as I don't see any reasons to still support python2, with all the overhead. Of course, this argument does not apply for existing distros :D Looking at specfiles of other distro (here I chose epel for centos), I see some differences: * Automatic Python Provides (see other thread): e.g.: %{?python_provide:%python_provide python3-setuptools} * Switches for wheel-packages, e.g. (here from python3-setuptools): %build %if 0%{?build_wheel} %{__python3} setup.py bdist_wheel %else %{__python3} setup.py build %endif What's the status here? I don't see any wheel-packages in /usr/lib/python3.5/site-packages/, but I'm sure most of them support wheel. * Additionally to the previous, Fedora specfiles (here a extract from python-psutil) use macros for buils: %build %py2_build %py3_build %install %py2_install %py3_install Combined with the previous point (wheel), could we use such macros and additionally detect wheel-capacity to build packages as wheel if possible? Therse are my thoughts that came to my mind in the last days, Sebastian -- python programming - mail server - photo - video - https://sebix.at cryptographic key at https://sebix.at/DC9B463B.asc and on public keyservers
Hi, On Thu, Aug 18, 2016 at 03:06:07PM +0200, Sebastian wrote:
Hi,
On 08/16/2016 12:00 PM, Bruno Friedmann wrote:
3) Python / Python3 : How to fix our mess, and create a bright future.
If packaging can be fun, the inverse can be true. I believe we are the last community that package python 2 et python 3 version in a separate way. This has already cause some grief, and we really need to fix it, no?
I've already heard that there's reasons behind the choice made. But we lack the fundamentals, as they are not clearly explained on obs project's page, nor in the wiki. So if new comer, like me arrived and try to understand how it works, you spend too much time on guessing and SR try and errors.
With the py2/py3 split, we also tend to forget to update one or the other repository (py2pack need to be fixed and improved to handle that), and we also have constants divergences between the 2 specs, which will increase errors, lost tracking bugs, or have version specific bugs.
This will (or did it already) kill any efforts to bring new hands to help. Ease our live (packager, users, bugfix & so on), and also get a coherent eco- system around python technology.
3.a What about opening a real discussion about our Python situation - Be it here on packaging list with a simple [python] prefix in the subject - Be it on a discussion page in the wiki (if editing is now fixed) - Be it (creative minds your input here) * I'm really interested by feedback or thoughput of SUSE's employee in charge of LTS support. More we will work together, better the solution will be.
3.b Prepare a kind of RFC for Python at openSUSE - Publish (even on news) and explain where comments should goes, so we can track and pick the good ideas - Organize obs structure to handle the changes (hello obs guru) - Put the changes in action (Hey why not then a pyckaton for that stuff?)
We don't need a super-heros here, I'm more confident in the fact that a team that want to achieve a collective forward can make it better than any individual effort. Unfortunately, there haven't been any comments on this section. But I'd too like to see improvements here.
* The py2/py3 split for devel-projects and thus all packages is very annoying IMHO. Supporting two packages per specfile would decrease the effort. But is this actually possible with OBS currently?
Sure. You just have 2 %package sections in your .spec .
I personally only support py 3 for any new packages I want to package and push to openSUSE, as I don't see any reasons to still support python2, with all the overhead. Of course, this argument does not apply for existing distros :D
I'm working for SUSE on OpenStack and this is all based on Python2. There are efforts upstream to make OpenStack useable with Python3 but this is not yet ready. So I'm currently only working on Python2. If the specs would build both versions (if possible) I would automatically do a lot of work for Python2 and Python3. So using a single spec for both versions would be very welcome.
Looking at specfiles of other distro (here I chose epel for centos), I see some differences: * Automatic Python Provides (see other thread): e.g.: %{?python_provide:%python_provide python3-setuptools} * Switches for wheel-packages, e.g. (here from python3-setuptools): %build %if 0%{?build_wheel} %{__python3} setup.py bdist_wheel %else %{__python3} setup.py build %endif What's the status here? I don't see any wheel-packages in /usr/lib/python3.5/site-packages/, but I'm sure most of them support wheel. * Additionally to the previous, Fedora specfiles (here a extract from python-psutil) use macros for buils: %build %py2_build %py3_build
%install %py2_install %py3_install
Having theses macros would be nice. For some of the OpenStack packages we already use them because we share the .spec files with Fedora and Mirantis. Best, Tom -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (13)
-
Bruno Friedmann -
Dominique Leuenberger / DimStar -
Hans-Peter Jansen -
Jason Craig -
Ludwig Nussel -
Michael Matz -
Michael Ströder -
Robert Schweikert -
Sebastian -
Sebastian -
Simon Lees -
Thomas Bechtold -
Todd Rme