Sounds good, thanks.

It looks like sqlalchemy completely changed their API with version 2.0...

I'm not sure however how package installs specify which version of sqlalchemy to install on Alpine? So I don't know if this patch would be premature. All I know is that with setup.py, my latest upgrade grabbed sqlalchemy 2+.

# HG changeset patch
# User Ludovic Chabant <ludovic@chabant.com>
# Date 1684262080 0
#      Tue May 16 18:34:40 2023 +0000
# Node ID 429f5c2a99742fdc2fd0c7bbbbcc7461f5b5610f
# Parent  2240911d9025c8a5b874085917cd13166e80e6ab
Upgrade hgsrht-shell to sqlalchemy 2.0 API usage

diff --git a/hgsrht-shell b/hgsrht-shell
--- a/hgsrht-shell
+++ b/hgsrht-shell
@@ -7,6 +7,7 @@
 import sys
 from datetime import datetime
[message trimmed]

> So my question is: is this a packaging bug? I'm thinking that if
> that user's shell would be set to /bin/sh in the post-install script,
> the issues I've described wouldn't happen. Or maybe administrators are
> supposed to do things I've described (changing user's password and
> shell)?

It does indeed look like a bug in the post-install script. I can't say
why it was written like this since I'm running my sourcehut instance on
Ubuntu and not Alpine, but the similar post-install script for git.sr.ht
does setup the git user with /bin/sh. It apparently used to be
/sbin/nologin, but was changed to /bin/sh with:

https://git.sr.ht/~sircmpwn/sr.ht-apkbuilds/commit/a411788b6c2472b4a74a5cc96c2d72e6400be206#sr.ht/git.sr.ht/git.sr.ht.post-install

Sounds good, thanks!

Thanks. I see this is part of a broader change -- does it depend on the
other commits, or can they all be submitted independently?

I'll wait to see if Drew accepts those other changes anyway.

Merged as b4d5c6f7058e, thanks!

> While it is true that the config has the "git.sr.ht::dispatch" entry,
> the actual code uses "hg.sr.ht::dispatch" as the section [0][1]

Ah right, I believe that code is wrong indeed.

Thanks for the patches! Merged v2 of this, and the other one, as
f70a9cacb505 and 6584a267226c

> For git.sr.ht, these fields are not used for cloning. Instead, that 
> information is stored in the repository by git.

Right, thanks. Merged as 6584a267226c

Since this stuff is already there, would it be worth it to implement the
cloning + upstream URI feature on hgsrht?