Formula DSL for Dependencies on X11 Components Optionally Used From or Provided By XQuartz?

[RandomDSdevel]

     Regarding Homebrew/homebrew-core#64166, I wonder if some DSL like 'uses_from :XQuartz <formula-provided X11 sub-library>' and/or 'provided_by :XQuartz <formula-provided X11 sub-library>' might turn out to be something desirable.

---

     (Some additional thoughts:

• Admittedly, then 'uses_from_macos <formula>' and 'provided_by_macos <formula>' not being 'uses_from :macOS <formula>' and 'provided_by :macOS <formula>,' respectively, would seem a bit weird.
• I don't also mean to suggest that this mean ':XQuartz' — or even ':macOS,' for that matter — should/would then become Requirements again, of course. Possibly tangentially related:
  • I can't find any high-level tracking issues about Requirements being removed from Core after an initial, cursory search, so, at the moment, I still lack the context to understand why it was decided this would happen. That being said, I don't intend to dispute the resulting changes here.
  • Requirements are different from regular inter-formula dependencies, but I can't recall what cases of problems with the former might have cropped up recently just off the top of my head.)

[RandomDSdevel]

     For some additional context, this thought crossed my mind because, as far as I'm aware, XQuartz is still the semi-official/recommended X11 distribution for macOS (even though it hasn't seen a new release in some time.)

[d235j]

Upstream has not provided guidance, and tells people to "use Xorg from MacPorts" when asked about newer versions. See #205 for a write-up.

[gromgit]

As the linked issue says:

This is part of our long-term goal to remove all cask Requirements from Homebrew/core, which will help speed up our CI deployment time.

I'm not a maintainer, but I can see a couple of other upsides to moving all X11 formulae away from building with XQuartz libraries:

• they will now link against the latest-n-greatest client libraries, with all the new features and (very important) timely security fixes
• they should now be more cross-platform, with less special-case code, compatibility issues and (hopefully) manual work for the Linuxbrew maintainers

There's currently no reasonable FOSS substitute for XQuartz as a display server, but limiting the "exposure" of client software to an aging project is a Good Thing IMO.

[d235j]

There's currently no reasonable FOSS substitute for XQuartz as a display server, but limiting the "exposure" of client software to an aging project is a Good Thing IMO.

It seems that XQuartz upstream is recommending people install Xorg and dependencies via MacPorts, where they and MacPorts contributors are maintaining it — see #205.

[jonchang]

I wonder if some DSL like 'uses_from :XQuartz ' and/or 'provided_by :XQuartz ' might turn out to be something desirable.

These are basically Requirements, which as the linked issue says, we are moving away from. See https://docs.brew.sh/Building-Against-Non-Homebrew-Dependencies for some history.