Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Plans for eventually using published pubgrub? #3794

Closed
musicinmybrain opened this issue May 23, 2024 · 4 comments
Closed

Plans for eventually using published pubgrub? #3794

musicinmybrain opened this issue May 23, 2024 · 4 comments
Labels
question Asking for clarification or support

Comments

@musicinmybrain
Copy link
Contributor

I noticed that pubgrub is one of two dependencies that uv currently needs to fork (https://github.com/astral-sh/pubgrub), with async_zip being the other. I also noticed that there seems to be ongoing work toward minimizing the changes in the fork, e.g. #3713, astral-sh/pubgrub@eeb63dd.

For the benefit of distribution packagers and others who need to treat git dependencies specially, could you please comment briefly on whether you have a plan for eventually using the published pubgrub crate?

@konstin
Copy link
Member

konstin commented May 23, 2024

We unfortunately require api-breaking changes to pubgrub and access to some of the internals that will not be exposed in the published version. While we have been and will be spending significant effort into upstreaming our changes (https://github.com/pubgrub-rs/pubgrub/pulls?q=is%3Apr+author%3Akonstin), we unfortunately do not have plans to switch to a crates.io version of pubgrub.

@musicinmybrain
Copy link
Contributor Author

Thanks! Even if the fork will be maintained indefinitely, the statement and explanation is valuable.

@zanieb
Copy link
Member

zanieb commented May 23, 2024

We could vendor it within uv itself if it makes a big difference externally. We generally find it easier to maintain the fork in a separate repository though.

@zanieb zanieb added the question Asking for clarification or support label May 23, 2024
@musicinmybrain
Copy link
Contributor Author

We could vendor it within uv itself if it makes a big difference externally. We generally find it easier to maintain the fork in a separate repository though.

In Fedora, we handle git crate dependencies by adding an additional source archive, like https://github.com/astral-sh/pubgrub/archive/0e684a874c9fb8f74738cd8875524c80e3d4820b/pubgrub-0e684a874c9fb8f74738cd8875524c80e3d4820b.tar.gz, to the source RPM. Then we extract it and patch the git crate dependency into a path one.

This is perhaps a little more effort than dealing with an “in-tree” vendored/bundled crate, but not much more, as long as the number of such crates is small. Plus, this method has the advantage that it’s explicit, with no chance of missing vendored/bundled code that we needed to document and justify to satisfy our packaging guidelines. So I can’t speak for other distributions, but I’m perfectly happy with the way these two forked crates are managed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Asking for clarification or support
Projects
None yet
Development

No branches or pull requests

3 participants