Move Kconfiglib to Zephyr's GitHub org

[carlescufi]

Introduction

As per the conclusions in ulfalizer/Kconfiglib#121, Kconfiglib needs a new home and a new maintainer. @jackrosenthal has volunteered to maintain it, and the Zephyr TSC agreed to host the project under the Zephyr GitHub org.

Problem description

Given that the pypi package repository contains the official Kconfiglib packages and that the original author, @ulfalizer, is the only person with the credentials required to update that package, the only reasonable solution is to fork and rename the library to be able to publish new versions to pypi.

Proposed change

1. Fork https://github.com/ulfalizer/Kconfiglib into the https://github.com/zephyrproject-rtos org
   • https://github.com/zephyrproject-rtos/Kconfiglib
2. Make all the necessary changes to rename the package, including renaming the repo itself
3. Publish regularly on pypi with the new name, using the Zephyr credentials

Proposed names

Here's a few names that could be considered:

• Kconfiglib2
  • This is my preference because it clearly shows it's a fork of the original Kconfiglib, and it also conveys that our intent was not to rename it but we had to
• Pykconfig
• Kconfig
• python-kconfig

[carlescufi]

@marc-hb @mbolivar-nordic @tejlmand @nordicjm @stephanosio @fschrempf @gmsotavio

[nashif]

one more...
python-kconfig

[mbolivar-nordic]

• This is my preference because it clearly shows it's a fork of the original Kconfiglib, and it also conveys that our intent was not to rename it but we had to

If Ulf ever comes back and wants to release a version 2, we'll have problems.

[sjg20]

Do we need to rename it? Could we take over the project and continue with the same name?

[jackrosenthal]

• Kconfiglib2 - Could be confusing, as kconfiglib is currently at version 14.1 (and 2 < 14.1).
• Kconfig - OK as there's nothing on PyPI with this name, but could be difficult to search for on Google, GitHub, etc, as the name is not unique from Linux's C-based Kconfig.
• pykconfig, python-kconfig - Both of these seem fine to me. pykconfig is particularly appealing as it has no hyphen, so the package name can be the same name as the module you import.

So my vote is on pykconfig.

Do we need to rename it? Could we take over the project and continue with the same name?

It looks like that's something we could request: https://peps.python.org/pep-0541/#how-to-request-a-name-transfer

[carlescufi]

Do we need to rename it? Could we take over the project and continue with the same name?

It looks like that's something we could request: https://peps.python.org/pep-0541/#how-to-request-a-name-transfer

Let's give this a go. I will create a request today and link it.

[carlescufi]

@jackrosenthal here's the request: pypi/support#2526

[galak]

pykconfig +1

[fabiobaltieri]

Kconfiglib-ng? Traditional open source optimistic fork name.

[marc-hb]

python-kconfig

There are 103 Python packages that debian has named by adding a python- prefix to their original name: https://packages.debian.org/bullseye/python/

So if python-kconfig is ever packaged by Debian they could call it python-python-kconfig.

Same thing for Fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_library_naming

Of course Debian and Fedora wouldn't actually do that; I'm merely recommending that Zephyr does not "steal" a very popular naming convention already used by Linux distributions to avoid confusion.

My strong, first preference is to reclaim the existing name if possible, as already requested by @carlescufi. The least disruption by far. I'm optimistic: if this process does not work when the maintainer vanishes then when does it work?

My second preference is pykconfig: short, simple and to the point. No hyphen, no mixed case,...

[sjg20]

It looks like the requests are being actioned, at least some of them. I added my support into the issue

[gmsotavio]

Hello

My thoughts about the subject

Kconfiglib2 - This name sounds fine to me, but I agree with @jackrosenthal that it can be confusing.
Kconfig - May be confused with Linux Kconfig. So it seems like a bad idea.
python-kconfig - That's ok, but this is the default name for Debian packages. So I agree with @marc-hb that if python-kconfig is packaged by Debian they could call it python-python-kconfig. So, I think this name is not optimistic.
pykconfig - The best of the proposed names.

As pointed out by @fabiobaltieri, we could name this project Kconfiglib-ng.

Summing up, +1 vote to Kconfiglib-ng as it may indicate that it's a fork. My second option is pykconfig.

But, for now, it is best to wait for an input for the request sent by @carlescufi to https://peps.python.org/pep-0541/#how-to-request-a-name-transfer

[jackrosenthal]

So the name transfer appears to be going nowhere. Anyone opposed to just renaming to pykconfig? Seems like a simple find/replace op.

[keith-zephyr]

The feedback we got from one of the pypi maintainers is that requests are handled first-in/first-out. But because everyone is a volunteer, one should expect a slow response time.

[marc-hb]

From

• PEP 541 Request: Kconfiglib pypi/support#2526

Hi all, I will now start the reachability process for your request which can take up to 6 weeks. Thank you for gathering resources regarding the owner, hopefully we can get a response soon and proceed with the transfer.

[marc-hb]

pypi/support#2526 (comment)

Owner role on kconfiglib Project granted to zephyr-project.

[carlescufi]

I can confirm that the zephyr-project account in PyPi now manages the Kconfiglib project:
https://pypi.org/project/kconfiglib/

[carlescufi]

@jackrosenthal can you confirm that you are still interested in maintaining Kconfiglib?

[jackrosenthal]

Yeah, I'm still available to help maintain kconfiglib!

[carlescufi]

Concluding on this issue:

• Repo is now available in https://github.com/zephyrproject-rtos/Kconfiglib (@jackrosenthal has write access)
• PyPi package is now owned by Zephyr

TODO: @jackrosenthal can you comment on all PRs and issues in https://github.com/ulfalizer/Kconfiglib redirecting users to https://github.com/zephyrproject-rtos/Kconfiglib?

[carlescufi]

Closing this issue as this is effectively complete.

[carlescufi]

Reopening because I now realize we have some commits in Zephyr's own kconfiglib copy (yes, we don't use the PyPi package) that would need to be backported to the new upstream @jackrosenthal:
https://github.com/zephyrproject-rtos/zephyr/commits/main/scripts/kconfig/kconfiglib.py

[carlescufi]

Now complete.