Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arch Linux package? #237

Open
blacklight opened this issue Mar 26, 2023 · 4 comments
Open

Arch Linux package? #237

blacklight opened this issue Mar 26, 2023 · 4 comments

Comments

@blacklight
Copy link

blacklight commented Mar 26, 2023

I'm the creator and maintainer of Platypush, I have recently discovered this module and I love it so far!

After a bit of a learning curve to adapt to the new patterns, I've started migrating at least some of the existing vanilla Marshmallow schemas in my project to dataclasses - and life if much easier now that I have stuff like IDE autocompletion on objects rather than dicts.

The problem is that the Platypush package is on the AUR, and this module is not, so I'm holding back on adding the dependency on marshmallow_dataclass because otherwise I'd have to document the extra manual step of installing this package via pip.

Is there interest in distributing marshmallow_dataclass on AUR as well? If there's enough traction I could also see this being merged in the official community repo.

I'm also happy to bootstrap a PKGBUILD and upload it to the AUR as a temporary unofficial maintainer if it's ok for you folks, since it's in my interest to get this on AUR ASAP, so I can merge and release my changes that use this module as an addition to the plain Marshmallow.

@blacklight
Copy link
Author

blacklight commented Mar 26, 2023

I have proceeded to create and upload an AUR package in the meantime, so I can proceed and prepare a new release of Platypush with all the mandatory dependencies available on the AUR.

I've tested it on several of my machines and it seems to work.

Let me know if you folks want to take over it, or maybe integrate the release in your CI/CD pipelines.

@dairiki
Copy link
Collaborator

dairiki commented Mar 29, 2023

@blacklight Thank you for your efforts!

I am a maintainer, but not the owner, of marshmallow_dataclass, so I speak only with tentative authority.
Also, I am not very familiar with Arch, AUR, or its packaging mechanics.

If you're willing to continue to maintain the AUR package, then I think that's great!

If it's straightforward to integrate the AUR packaging/release with our CI workflow, I'm all for it. Feel free to submit a PR for that. Also, feel free to reach out if I can help with that from this end.

@blacklight
Copy link
Author

Hi @dairiki, thanks for reaching back!

Maintaining a distribution package is relatively simple, but I proposed of integrating the process into the CI pipeline so I don't have to do it manually upon a new release.

The PKGBUILD format is quite straightforward, in the one I've uploaded basically you just need to update pkgver and the sha512sum of the package when there's a new release.

A PR that integrates it in Github Actions shouldn't be hard to put together, the only problem is that the process involves cloning the git repo of the package and pushing the changes with an SSH key that is allowed to modify the repo. So I guess that I either need a spare RSA pubkey that can be used in the CI process (and add it to the authorized keys for the repo), or use my own?

@dairiki
Copy link
Collaborator

dairiki commented Mar 30, 2023

@blacklight Here's a GitHub action that purports to (I think) do what's needed: https://github.com/ulises-jeremias/github-actions-aur-publish
(There are quite a few similar actions listed in the marketplace — I picked the one with the most stars.)

As you say, these would involve generating a new SSH key pair for our CI to use to push the new releases. The new private key would be stored as one of our project secrets. (I don't think I have permission to set new secrets on the project, but I'm fairly sure @lovasoa would help to get that done.)

====

Another option that would avoid having to grant our CI push permission is to work up a script on your end that would pull the required information from GitHub's tags API. Or we could start making GitHub releases for each release and you could use GitHub's release API.

That script could either be run manually when there is a new release or it could be run periodically, polling for new releases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants