On 8/21/23 20:31, Dominik George via openSUSE Factory wrote:

Heisan,

this topic came up during my submission of python-mmllib to the Python devel project [1]. But, in fact, it seems to be a quite general discussion, so I am raising it here to get a general picture.

As a side note, my current endeavour is exploring the maintenance, especially team maintenance and mentoring approaches, of packages in openSUSE, in comparison to how it is handled in Debian. I am a Debian Developer and therefore quite used to the workflows and basic approaches over there.

The general question I'd like to discuss is where libraries for development in various languages should be maintained. There are development teams for all major languages, and these seem, to some extent, to maintain development libraries as well.

Then, looking at MMLlib as an example, this package can be seen in two ways:

* it is a library that can be used for various kinds of programs written in Python, among which are games, educational toys, and multimedia applications * it is not _really_ generic, as it is somewhat specialized in not only, but probably mostly the fields mentioned above

So, in *theory*, MMLlib is a generic library that can be used by whoever thinks they need it in their program, but in practice, it will be mostly useful for the mentioned fields.

Matej therefore proposed it be moved to another team, with the Education devel project in mind (because education is the field where I, also being the upstream maintainer, developed it).

I, i ncontrast, are still in favour of having all sorts of Python libraries maintained in a language team. Let me summarize what I think are the arguments for the two approaches:

a) Maintaining all development libraries in a single language project

- high maintenance load for a single team - large collection of packages in a single, probably not too well namespaced bunch + simplified auto-maintenance and batch changes + better control over adherence to library packaging guidelines

b) Maintaining specialised libraries in topical projects

- less control over adherence to library packaging guidelines - not clear which topic fits the best (see example above) sometimes + less maintenance burden for a single team

Probably the main advantage for having a package that is only really used by one set of applications be it games or multimedia etc is when that package is updated and sent to the devel project you can already verify if that package is going to break some of the applications that use it as they all sit in the same devel repo. multimedia:libs for example has python bindings for alsa and gst because that's where most of the applications that use those libraries live. Similarly games has the python libraries for SDL2 and pygame among other thngs. Then another semi related case is I keep the efl widget toolkit bindings python-efl with the efl libraries. You can probably equally find examples in devel:languages:python that could also be elsewhere. But 2000 packages in a single devel repo is alot to manage so for me if something makes sense in another devel repo the existing size of the repo is atleast a reason to ask these questions. But if a library is being used by packages in 3-4 other devel repo's then devel:languages:python might really be the best place.

Closely related to this question is the question whether development libraries should go into the distribution at all. More recently, I found the stance of the Go language team on that [2]. In conclusion, this is "we do not want a large collection of development packages in the distribution, only those needed to build and run leaf binaries". Taht implies that developers who use openSUSE for their work are told to use non-openSUSE sources instead, and install development libraries from the repositories provided by their language ecosystem, and that we make a clear distinction:

* packages in openSUSE are for end users * developers use their language ecosystem tools

Generally, I am in favour of providing all tools, including libraries, for everyone in a distribution, but that's a very "Debian" view of things. In practice, it shows that for Python development, virtual environments managed with poetry or whtever, and installing packages from PyPI, is far better suited. So I am somewhat moving into that direction.

But then again, I find it questionnable that the Go language team should be responsible for maintaining any binary leaf packages. Why is teh Go devel project responsible for maintaining, say, hugo [3], and not a devel project tailored at website topics?

The general approach of openSUSE is that if someone feels that a python library is useful enough for that person to put the effort into contributing it and maintaining it in a openSUSE distro then that's good enough reason to include it. SUSE Tends to only include libraries that are needed by the applications it ships so generally anything else that currently exists in openSUSE is going to fit the someone thought it was useful category. Personally I've occasionally contributed python libraries because I have a script or tool that needs them and enough of the other dependencies already exist in openSUSE that its easier to just package the one or two other libraries then go to the hassle of setting up pip. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B