Distro packaging for Hawkmoth

[jnikula]

Due to the dependency on native Clang and its Python bindings, not available via pip, the installation of Hawkmoth can be a bit tricky. It would be great to have Hawkmoth packaged and available in distro package repositories.

I could really use some help here.

There's the Arch AUR package https://aur.archlinux.org/packages?K=hawkmoth by @BrunoMSantos, and then there's the old packaging request for Debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996357 but that's pretty much it.

[BrunoMSantos]

There's the Arch AUR package https://aur.archlinux.org/packages?K=hawkmoth by @BrunoMSantos

FYI, the package has just been adopted into the official extra repository under the same name 🎉
I'll still maintain the -git version in AUR though.

[stephanlachnit]

FYI in principle I am a Debian Developer and can help to upload it, but I don't plan to do the initial packaging.

[jnikula]

FYI in principle I am a Debian Developer and can help to upload it, but I don't plan to do the initial packaging.

I can (learn to) do the packaging, and shove it in a repo, but could you point me at some Debian Python packaging documentation/examples that would be to your liking, please?

[stephanlachnit]

Sorry for the late reply, I was on vacation the last weeks.

A good example would be REUSE, which lives here. The Debian packaging is fully contained in the debian folder. A simple tutorial can be found here: https://wiki.debian.org/Packaging/Intro. For details check the Debian Policy Manual and Debian Python Policy.

Once you are done, you want to put the packaging onto Salsa, Debian's GitLab instance. There is a tool to help with the branch layout called gbp, check https://wiki.debian.org/Python/GitPackaging for more details. I will do the final upload then.

Feel free to contact me if you need assistance.

[Cynerd]

I am trying to push it to Nixpkgs and thus to NixOS here NixOS/nixpkgs#385824.

[LecrisUT]

I could look into the Fedora packaging. But on the pip distribution side, there is a push to upstream the bindings llvm/llvm-project#125806. Afaict it still needs the library itself, but it is a step forward.

[jnikula]

I could look into the Fedora packaging.

That would be appreciated!

But on the pip distribution side, there is a push to upstream the bindings llvm/llvm-project#125806. Afaict it still needs the library itself, but it is a step forward.

Yes, it would be great to have official bindings on pypi. I'm a bit hesitant to recommend what's currently in there, because that would imply I'm somehow vouching for them, but I think they're unofficial, and I really have no clue about them. There's at least:

• https://pypi.org/project/clang/ which is just the bindings.
• https://pypi.org/project/libclang/ which also has the library, and is ostensibly owned by the LLVM org, but I really have no idea if that's truly LLVM or just something someone registered.

Do you have any idea yet if there's going to be yet another project on pypi for the official bindings, or can you somehow take over either or both of the existing ones?

[LecrisUT]

Do you have any idea yet if there's going to be yet another project on pypi for the official bindings, or can you somehow take over either or both of the existing ones?

The canonical place that LLVM will have control over will be libclang as far as I was notified ¹. The clang project could also be merged and have one point to another, but probably will not happen until all the pieces are in place to build in upstream. The current version on the LLVM repo does not have the bundled library, more iterative work is needed to get the pieces connected there, but could probably notify once everything is in place.

I could look into the Fedora packaging.

That would be appreciated!

Cool, at first glance, everything seems to be in order for the packaging, just some questions on how do you want to do:

• Would you want to move to PEP639 license format in upstream or would you want it only in downstream patch for now. It matters depending on what version of hatchling is available to build in the downstream distro, but the downstream packagers can conditionally apply/revert a patch depending on their need, it mostly depends on your maintenance policy
• How far back would you want this to be supported in LTS distros, only the latest lts only, no lts distro at all, as far back as possible until it becomes a burden? For a project like this it matters because you might not have many choices of clang on those distros
• Would you care to have fedora-rawhide CI included in this repo to build and test against the latest clang available there? I believe there are also some copr projects that could pull in unreleased versions as well and we can help you integrate with that as you prefer.

Footnotes

1. https://github.com/pypi/support/issues/8202 ↩

[jnikula]

• Would you want to move to PEP639 license format in upstream or would you want it only in downstream patch for now. It matters depending on what version of hatchling is available to build in the downstream distro, but the downstream packagers can conditionally apply/revert a patch depending on their need, it mostly depends on your maintenance policy

Ah, looks like what I have now has been deprecated. I prefer to follow the current recommendations, so I'll fix this.

• How far back would you want this to be supported in LTS distros, only the latest lts only, no lts distro at all, as far back as possible until it becomes a burden? For a project like this it matters because you might not have many choices of clang on those distros

As a rule of thumb, I don't want to depend on things that are only available on the latest distros. If you look at the docker directory, I test on all of those before release. The only catch is that the testing does use latest from pypi. I'd like to try only depending on Python packages available via the distro package repositories, but haven't gotten around to it yet. In any case, I test on whichever libclang and bindings are available on those distros.

I realize I'm not answering your question directly, but does that give you an idea what to do?

• Would you care to have fedora-rawhide CI included in this repo to build and test against the latest clang available there? I believe there are also some copr projects that could pull in unreleased versions as well and we can help you integrate with that as you prefer.

Maybe. I'm not quite sure what exactly this would mean. Some github workflow setup? But I do know that we hit issues with new clang releases regularly, and usually fedora-rawhide is where I can reproduce them. Would be nice to catch issues in CI before user reports.

[LecrisUT]

Maybe. I'm not quite sure what exactly this would mean. Some github workflow setup?

The tool is packit, but yeah, basically it would just be a CI that does an rpm build equivalent with what would be done in downstream. It would basically just build the exact current state of the repo, and allow us (fedora downstream) to collaborate more easily.

As a rule of thumb, I don't want to depend on things that are only available on the latest distros.

Understood, and no worries, it's a common sentiment, and we just want to set the expectations on both side. I will go with as back as possible until there are blockers, currently being rhel 9, 10.

I'd like to try only depending on Python packages available via the distro package repositories, but haven't gotten around to it yet. In any case, I test on whichever libclang and bindings are available on those distros.

We will help you with that with packit of course for rhel-like distros. But if you find you need anything updated, feel free to ask and I can stir the nest a bit and see if we can do something or find a workaround.