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
signature.asc
Description: PGP signature
