-
Notifications
You must be signed in to change notification settings - Fork 970
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
Comments
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. |
Thanks! Even if the fork will be maintained indefinitely, the statement and explanation is valuable. |
We could vendor it within |
In Fedora, we handle 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. |
I noticed that
pubgrub
is one of two dependencies thatuv
currently needs to fork (https://github.com/astral-sh/pubgrub), withasync_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?The text was updated successfully, but these errors were encountered: