[aur-general] Package Request and/or TU Application
Hi aur-general, I've come across a Python library which serves a nice purpose for aurweb's FastAPI implementation, but noticed that it is not yet maintained in the Arch official repositories. For aurweb, we'd like to stick to packages which exist within our official repositories, and so I'm here to start a chat about either someone picking it up or applying as a TU to maintain it. Upstream: https://github.com/Pylons/paginate Description: A Python pagination module I've put together an AUR package for this project to share/demonstrate its PKGBUILD that could be used to produce a [community] package, located at https://aur.archlinux.org/packages/python-paginate/. There are other python-*-paginate libraries around the AUR, but they are not meant to be as standalone as Pylon's paginate seems to be (out of the box, at least). For any TUs out there, could you perhaps give some feedback as to your thoughts on the package topic? It'd be greatly appreciated. That being said, I could maintain the package, but I have not really reached out to TUs to get any sort of sponsorship in regards to this, as I do not really have many packages that I know of to pick up. My main goal here is to get `python-paginate` into [community], however that may be achieved. Would this be possible? Thanks for your time and willingness to read this. Regards, Kevin Morris -- Kevin Morris Software Developer Identities: - kevr @ Libera
Em agosto 19, 2021 16:46 Kevin Morris via aur-general escreveu:
Hi aur-general,
I've come across a Python library which serves a nice purpose for aurweb's FastAPI implementation, but noticed that it is not yet maintained in the Arch official repositories. For aurweb, we'd like to stick to packages which exist within our official repositories, and so I'm here to start a chat about either someone picking it up or applying as a TU to maintain it.
Upstream: https://github.com/Pylons/paginate Description: A Python pagination module
I've put together an AUR package for this project to share/demonstrate its PKGBUILD that could be used to produce a [community] package, located at https://aur.archlinux.org/packages/python-paginate/.
There are other python-*-paginate libraries around the AUR, but they are not meant to be as standalone as Pylon's paginate seems to be (out of the box, at least).
For any TUs out there, could you perhaps give some feedback as to your thoughts on the package topic? It'd be greatly appreciated.
That being said, I could maintain the package, but I have not really reached out to TUs to get any sort of sponsorship in regards to this, as I do not really have many packages that I know of to pick up.
My main goal here is to get `python-paginate` into [community], however that may be achieved.
Would this be possible?
Thanks for your time and willingness to read this.
Regards, Kevin Morris
-- Kevin Morris Software Developer
Identities: - kevr @ Libera
Is there any specific reason not to use virtualenvs for aurweb deployments? We have a few python services, some use repo packages, some use virtualenv's. Both have pros and cons, but our heaviest stuff, which is archweb, uses a venv, because it has a bunch of deps and also because we can't always update the django version without issues. I never used fastapi, but I presume there might be breaking changes between versions. We shouldn't postpone upgrading the aurweb server because of this. If some TU wants to maintain it, fine. But, for the actual deployment, I wouldn't use repo packages. Regards, Giancarlo Razzolini
On 2021-08-19 22:46, Kevin Morris via aur-general wrote:
Hi aur-general,
I've come across a Python library which serves a nice purpose for aurweb's FastAPI implementation, but noticed that it is not yet maintained in the Arch official repositories. For aurweb, we'd like to stick to packages which exist within our official repositories, and so I'm here to start a chat about either someone picking it up or applying as a TU to maintain it.
I'd be happy to move it to and maintain it in [community]. Caleb
On 2021-08-19 23:05, Giancarlo Razzolini via aur-general wrote:
We shouldn't postpone upgrading the aurweb server because of this. If some TU wants to maintain it, fine. But, for the actual deployment, I wouldn't use repo packages.
How you choose to deploy is only a little bit related. I can see the argument for wanting to pick libraries that are packaged by Arch if nothing else than just for the sake of the developers working on the project or test deployments or whatever. Even if the devops guys decide it's easier to maintain a deployment another way (as for example they do with GitLab that does not dogfood Arch's own packaging) that's fine. If it will serve the purposes of aurweb developers I'm happy to expedite it being in [community] and maintain it as the latest available upstream release. Caleb
I do like Giancarlo's idea because it would really future proof a lot of Python libraries we use; we could just lock versions in requirements.txt. It just feels a bit odd that we're splitting between two different package managers, especially because we still have to depend on several arch packages working properly regardless of the Python libraries. I think I'm going to in fact commit that in as a new route for Python dependencies within a few days; it'll at least remove a dependency on unmaintained packages in the future. That being said, I'd still vouch for the package in question for [community], as it's quite useful and seems like it's been stable for long enough in upstream. Regardless, thanks for taking a look and replying so quickly! Regards, Kevin On Thu, Aug 19, 2021 at 11:14:08PM +0300, Caleb Maclennan via aur-general wrote:
On 2021-08-19 23:05, Giancarlo Razzolini via aur-general wrote:
We shouldn't postpone upgrading the aurweb server because of this. If some TU wants to maintain it, fine. But, for the actual deployment, I wouldn't use repo packages.
How you choose to deploy is only a little bit related. I can see the argument for wanting to pick libraries that are packaged by Arch if nothing else than just for the sake of the developers working on the project or test deployments or whatever.
Even if the devops guys decide it's easier to maintain a deployment another way (as for example they do with GitLab that does not dogfood Arch's own packaging) that's fine. If it will serve the purposes of aurweb developers I'm happy to expedite it being in [community] and maintain it as the latest available upstream release.
Caleb
-- Kevin Morris Software Developer Identities: - kevr @ Libera
On 2021-08-19 23:24, Kevin Morris via aur-general wrote:
I think I'm going to in fact commit that in as a new route for Python dependencies within a few days; it'll at least remove a dependency on unmaintained packages in the future.
That being said, I'd still vouch for the package in question for [community], as it's quite useful and seems like it's been stable for long enough in upstream.
Lets hold off for a few days then and see what direction you go with aurweb. For now I think it's fine in the AUR until there is more clear direction. I don't want to package something that I don't use just because it might be generally useful for something or other. If it's actually needed for something then sure. Being able to run an aurweb instance using only distro packages is probably a worthwhile thing, but there doesn't seem to be a rush either. Don't let not being in [community] be a blocker for aurweb development, but lets hold off to see what the need is actually going to be. Caleb
Em agosto 19, 2021 17:24 Kevin Morris via aur-general escreveu:
I do like Giancarlo's idea because it would really future proof a lot of Python libraries we use; we could just lock versions in requirements.txt. It just feels a bit odd that we're splitting between two different package managers, especially because we still have to depend on several arch packages working properly regardless of the Python libraries.
I think I'm going to in fact commit that in as a new route for Python dependencies within a few days; it'll at least remove a dependency on unmaintained packages in the future.
That being said, I'd still vouch for the package in question for [community], as it's quite useful and seems like it's been stable for long enough in upstream.
Regardless, thanks for taking a look and replying so quickly!
Regards, Kevin
We can (and should) aim to have everything needed to run the new aurweb on the repos. Using virtualenvs has the downside of needing to sometimes be re-created and that can cause issues (we had psycopg issues on archweb). Also, we need to make sure we don't allow the deps to stale on it. Still, it allows the rest of the machine to be updated often, and this is specially important on the aurweb. We have a huge attack surface, it is by far our most important service to secure, given the SSH and webgit accesses, and everything else. I don't want us to have to hold an important kernel, openssh, etc, upgrade, because it would also bring in a new version of the libraries which would break the code. We also had issues with the php aurweb in the past where a new PHP version would break it, preventing the whole machine from being updated. Regards, Giancarlo Razzolini
participants (3)
-
Caleb Maclennan
-
Giancarlo Razzolini
-
Kevin Morris