uv
uv copied to clipboard
astral-sh
feat: add custom middleware
Summary
This adds the ability to the RegistryClient and BaseClient for the consumer of the library to add custom middleware. The problem is that we have different authentication methods/requirements for pypi registries and would like to use the middleware provided by https://github.com/mamba-org/rattler
I've decided that if you do this, it overrides the normal middleware. This makes the retries option, and maybe some others, not really do anything anymore. Which is a bit weird, but couldn't directly think of a better way to do it, as you might end up with 'duplicated' middleware maybe.
This should close the issue/question I made: https://github.com/astral-sh/uv/issues/3400
I'll make it a draft for now because I do not know how you feel about such a change and maybe there is a different design you have in mid.
Test Plan
Once, I can update to the latest uv version, I'll try and test things out directly in: https://github.com/prefix-dev/pixi. I'm happy to add rust test here if you know a good place for it.
Sorry for not replying to the initial issue! Yes we can support. What do you think about the branch in https://github.com/astral-sh/uv/compare/konsti/custom-middleware ? It's similar to yours but encapsulates the stack selection into MiddlewareStack.
Am i correct to assume you don't care about middleware for the offline case?
Hi Konsti, that looks a lot better actually! Good question about the offline, our middleware does not account for it yet, but if you feel it's better to add it to the offline case as well, that seems totally valid!
(force-pushing because i had to rebase on main, your initial commit should be preserved)
Hi all, just wondering if you guys are happy with the current design, and if rebasing is the only requirement for this PR to be merged?
Sorry, I need to review the latest implementation but am prioritizing things that impact more users right now.
Would still be very useful for us, however, as reqwest-middleware is now a forked version, I'm unsure regarding the compatibilities with the open-source version. However, we could re-vendor the middleware if needed :)
It looks like @konstin added AuthIntegration::NoAuthMiddleware allowing the auth middleware to be disabled so maybe we just need the ability to attach extra middleware now?
Sounds good, is there something you like me to change other than a rebase?
Can we drop all the MiddlewareStack stuff and just add a extra_middleware: Vec<Arc<dyn Middleware>> option? Or is there more that you need?
Not at all computer currently but sounds good to me, let me give it a go at the end of the week!