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