Skip to content

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

Open
1 task done
p-linnane opened this issue Apr 4, 2025 · 7 comments
Open
1 task done

Implement no_linkage DSL to cover dependencies without linkage #19697

p-linnane opened this issue Apr 4, 2025 · 7 comments
Labels
help wanted We want help addressing this

Comments

@p-linnane
Copy link
Member

Verification

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:

╰─ brew linkage awscli
System libraries:
  /System/Library/Frameworks/Security.framework/Versions/A/Security
  /usr/lib/libSystem.B.dylib
Homebrew libraries:
  /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib (openssl@3)
Dependencies with no linkage:
  cryptography

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:

depends_on "cryptography" => :no_linkage
╰─ brew linkage awscli
System libraries:
  /System/Library/Frameworks/Security.framework/Versions/A/Security
  /usr/lib/libSystem.B.dylib
Homebrew libraries:
  /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib (openssl@3)
Homebrew dependencies not requiring linkage:
  cryptography

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

@MikeMcQuaid
Copy link
Member

@p-linnane we previously had :run and :linked that we could resurrect; some code still exists for them. Would either of those names make sense? I think :run did exactly what you want here.

@p-linnane
Copy link
Member Author

So rather than declaring that a dependency won't have linkage, we'd use :run to indicate it's a runtime dep without linkage? I think that could work. It doesn't feel very clear to me from the name though, since there will be all the other runtime deps that do have linkage. That was why I was proposing :no_linkage since it's very explicit in what's expected. Do you think we could lift some of the remaining :run code into a :no_linkage?

@MikeMcQuaid
Copy link
Member

That was why I was proposing :no_linkage since it's very explicit in what's expected. Do you think we could lift some of the remaining :run code into a :no_linkage?

I think most of the code is gone. If you hate the :run name, cool, no problem, it's mainly just that it's a case that's previously been used.

I wouldn't be opposed to no_linkage or unlinked or something more explicit (provided it failed if there actually was linkage).

@p-linnane
Copy link
Member Author

It's not that I hate :run, it's just that I don't think it accurately describes what we're checking or confirming in this situation. Yes, it is a runtime dep, but the linkage is the thing we're primarily concerned about, since linkage happens with most runtime deps. I also agree it should fail if there is linkage, so we can investigate just like we do with the indirect deps with linkage. I'll think on it over the weekend.

@MikeMcQuaid
Copy link
Member

@p-linnane Cool, that's fair, I'm game for no_linkage or unlinked then.

@p-linnane p-linnane added the help wanted We want help addressing this label Apr 7, 2025
@gromgit
Copy link
Contributor

gromgit commented Apr 9, 2025

Third-party observation: I'd prefer no_linkage over unlinked, both to be consistent with the Dependencies with no linkage message, and to (hopefully) avoid confusion with brew unlink.

@MikeMcQuaid
Copy link
Member

@gromgit Good shout, thanks for your input. I'm 👍🏻 to no_linkage.

@MikeMcQuaid MikeMcQuaid changed the title Implement DSL to cover dependencies without linkage Implement no_linkage DSL to cover dependencies without linkage Apr 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted We want help addressing this
Projects
None yet
Development

No branches or pull requests

3 participants