I am new to this mail list, hence please let me know anything if I didn't do properly.

There is a GitHub repository (https://github.com/fancompute/ceviche) I want to pack it up as a python library for ez maintenance if there is any future update from the original authors.

Last, I attach my PKGBUILD file here. Please let me know if I should paste the script in the mail instead. Welcome and thank you for the contribution!

Unless a package produces architecture-dependent binaries, the architecture for Python packages is “any”. A quick overview of the repository shows that there is nothing platform-dependent there. Therefore `arch=(any)`. Otherwise I see no serious issues. The package builds here in a clean chroot. As for minor tweaks, I would change description to something a tiny bit neater. Like “Electromagnetic simulation tools for solving Maxwell's equations, with automatic differentiation”

Thanks for feedback from both of you, I will update a week later. 2022年6月19日(日) 3:40 Xiretza via aur-general

:

...

Dear,

I am new to this mail list, hence please let me know anything if I didn't do properly.

There is a GitHub repository (https://github.com/fancompute/ceviche) I want to pack it up as a python library for ez maintenance if there is any future update from the original authors.

Last, I attach my PKGBUILD file here. Please let me know if I should

On 19/06/2022 03.47, Dunzhi Zhou via aur-general wrote: paste

...

the script in the mail instead.

Thanks

Here are a couple issues I've found at a first glance:

1) Your package is a VCS package that always builds the latest commit from the upstream git repository. As per the VCS package guidelines[0], packages like this require a pkgver() function that can automatically generate a version number. 2) Since this is a pure python package that doesn't contain any platform-specific data, arch= should be 'any'. 3) The LICENSE should be installed to $pkgdir/usr/share/licenses/$pkgname/. 4) You should add `provides=("python-ceviche=$pkgver")` so that another package's dependency on 'python-ceviche' can be covered by this -git package, as well as `conflicts=(python-ceviche)` to avoid file conflicts in case someone creates a non-git package in the future.

Otherwise it looks fine to me; one more thing you might want to consider is to use the new, standardized python packaging approach as described in [1], but that's just optional future-proofing.

[0]: https://wiki.archlinux.org/title/VCS_package_guidelines [1]: https://wiki.archlinux.org/title/Python_package_guidelines#Standards_based_(...)