I've started working on pulling out contexts from structs per golang conventions

I think it depends on whether it really brings enough benefits. Golang itself (official packages, for example: http) also store the ctx into struct field in many cases .........

According to the go's blog post the only reason why net/http has context in its struct is backwards compatibility:
https://go.dev/blog/context-and-structs
And it's not recommended to store it there.

According to the go's blog post the only reason why net/http has context in its struct is backwards compatibility: https://go.dev/blog/context-and-structs And it's not recommended to store it there.

Yup, that's same to Gitea's code base. New code seldom stores context into a struct.

Some old code already stores the context into the struct, which is not good, while not too bad if it hasn't caused any problem (for example: markup render also does so). That's what I meant "I think it depends on whether the refactoring really brings enough benefits."

For "gogs downloader", the NewClient is quite lightweight, if you'd like to make the downloader support context, maybe it could re-create the client in every function.

As a refactoring PR, I think we'd better to make it move on fast (to avoid unnecessary conflicts)

If "gogs client ctx" is the last blocker, maybe I could help to try to figure out how to make it work (edit this PR) if you don't mind .......

Sorry for the delay, I started jumping between various topics semi-related (like what kind of magic makes gitea's context for request handlers) and unrelated (checking if migrating swagger to oapi-codegen is doable) to this.

I figured that probably the best solution is to make the gogs library have context support so I went ahead and added it in my fork.

I figured that probably the best solution is to make the gogs library have context support so I went ahead and added it in my fork.

Hmm, I prefer to keep using the official one (although it isn't active), in case the official one gets updated we might miss it.

The forked dependencies are difficult to maintain TBH. I think the gogs client ctx could be fixed by #33399 (comment)

The change isn't that big that a rebase once a while can't deal with. Though I see your point.
Can you share a snippet of code with your idea for a fix then? I figured you meant just creating new client per function but I don't see how context comes into play there...

-> Make gogs client work with context TheFox0x7#1

The reason why I don't want to introduce more forked packages:

• It takes extra work to maintain.
• It's difficult to follow upstream changes.
• If there is a dependency security vulnerability detected (by some bots/tools), our fork will miss it.

ps: see the comment for another fork (just below): // TODO: the only difference is in `PutObject`: the fork doesn't use `NewVerifyingReader(r, sha256.New(), oid, expectedSize)`, need to figure out why .........