-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
Implement no_linkage
DSL to cover dependencies without linkage
#19697
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
Comments
@p-linnane we previously had |
So rather than declaring that a dependency won't have linkage, we'd use |
I think most of the code is gone. If you hate the I wouldn't be opposed to |
It's not that I hate |
@p-linnane Cool, that's fair, I'm game for |
Third-party observation: I'd prefer |
@gromgit Good shout, thanks for your input. I'm 👍🏻 to |
no_linkage
DSL to cover dependencies without linkage
Verification
brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.Provide a detailed description of the proposed feature
We sometimes have formulae with runtime dependencies that do not have linkage. One example of this is
awscli
. For that specific formula,cryptography
is required at runtime, but there is no linkage:Given how much work we've done on fixing indirect dependencies with linkage, I think it's time to look in the other direction. I'm envisioning something like:
Naturally I'm proposing the concept here, rather than the exact wording and implementation. This would ensure that all dependencies that should be linked are, and that all dependencies that aren't linked are confirmed.
What is the motivation for the feature?
Tightening up our formulae, ensuring that every dependency declared is used correctly. We already are performing audits for indirect dependencies with linkage, so this would close the loop.
How will the feature be relevant to at least 90% of Homebrew users?
It wouldn't be. It would simply help us with maintaining formulae.
What alternatives to the feature have been considered?
Status quo
The text was updated successfully, but these errors were encountered: