graphviz: Why so many dependencies not in the list?

[chipbite]

Output of brew config

HOMEBREW_VERSION: 4.3.8
ORIGIN: https://github.com/Homebrew/brew
HEAD: e5f776b3e23cae8f1b6c3d1194b8329bf701965f
Last commit: 2 days ago
Core tap JSON: 02 Jul 16:41 UTC
Core cask tap JSON: 03 Jul 09:44 UTC
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CASK_OPTS: []
HOMEBREW_MAKE_JOBS: 8
Homebrew Ruby: 3.3.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/3.3.3/bin/ruby
CPU: octa-core 64-bit icelake
Clang: 15.0.0 build 1500
Git: 2.39.3 => /Library/Developer/CommandLineTools/usr/bin/git
Curl: 8.6.0 => /usr/bin/curl
macOS: 14.5-x86_64
CLT: 15.3.0.0.1.1708646388
Xcode: N/A

Output of brew doctor

Your system is ready to brew.

Description of issue

Hi there!
Background: I am creating a small setup script (macos) for installing a few different tools, where graphviz is one (used by plantuml). Choosing between ports and brew, trying the latter. New to homebrew and not really a mac user.

Problem: Running e g brew install graphviz started an installation that I thought would never end! ;-)

Count of dependencies in the repo are 6 (with 4 more for build. This obviously correspond to e g published web page with info).

When I ran it, it listed 51 dependencies.

Question 1: What is/can be the reasons for this?
Please see list of dependencies below.

Question 2: Can I avoid this or separate part of this? I mean, if some of this is some "base stuff" in some way, can I have the script do that first or something... (The install took such a long time, it will cause problems.)

Question 3, btw: I want to uninstall and test again, will try e g brew uninstall graphviz && brew autoremove. Any issues with this?

---

Info

Similar topics: #4839 & this on graphviz forum.

Output of brew install graphviz command (start atleast):

==> Downloading https://ghcr.io/v2/homebrew/core/graphviz/manifests/11.0.0
############################################################################################################################# 100.0%
==> Fetching dependencies for graphviz: libpng, freetype, fontconfig, jpeg-turbo, brotli, giflib, highway, imath, xz, lz4, zstd, libtiff, little-cms2, openexr, webp, jpeg-xl, libvmaf, aom, libavif, gd, pcre2, mpdecimal, ca-certificates, openssl@3, readline, sqlite, [email protected], gettext, glib, jasper, netpbm, gts, xorgproto, libxau, libxdmcp, libxcb, libx11, libxext, libxrender, lzo, pixman, cairo, gdk-pixbuf, fribidi, graphite2, icu4c, harfbuzz, pango, librsvg, m4 and libtool
==> Downloading https://ghcr.io/v2/homebrew/core/libpng/manifests/1.6.43

[...]

List of dependencies:

In order as they appeared:

     1  libpng
     2  freetype
     3  fontconfig
     4  jpeg-turbo
     5  brotli
     6  giflib
     7  highway
     8  imath
     9  xz
    10  lz4
    11  zstd
    12  libtiff
    13  little-cms2
    14  openexr
    15  webp
    16  jpeg-xl
    17  libvmaf
    18  aom
    19  libavif
    20  gd
    21  pcre2
    22  mpdecimal
    23  ca-certificates
    24  openssl@3
    25  readline
    26  sqlite
    27  [email protected]
    28  gettext
    29  glib
    30  jasper
    31  netpbm
    32  gts
    33  xorgproto
    34  libxau
    35  libxdmcp
    36  libxcb
    37  libx11
    38  libxext
    39  libxrender
    40  lzo
    41  pixman
    42  cairo
    43  gdk-pixbuf
    44  fribidi
    45  graphite2
    46  icu4c
    47  harfbuzz
    48  pango
    49  librsvg
    50  m4
    51  libtool

In alphabetical order:

     1  aom
     2  brotli
     3  ca-certificates
     4  cairo
     5  fontconfig
     6  freetype
     7  fribidi
     8  gd
     9  gdk-pixbuf
    10  gettext
    11  giflib
    12  glib
    13  graphite2
    14  gts
    15  harfbuzz
    16  highway
    17  icu4c
    18  imath
    19  jasper
    20  jpeg-turbo
    21  jpeg-xl
    22  libavif
    23  libpng
    24  librsvg
    25  libtiff
    26  libtool
    27  libvmaf
    28  libx11
    29  libxau
    30  libxcb
    31  libxdmcp
    32  libxext
    33  libxrender
    34  little-cms2
    35  lz4
    36  lzo
    37  m4
    38  mpdecimal
    39  netpbm
    40  openexr
    41  openssl@3
    42  pango
    43  pcre2
    44  pixman
    45  [email protected]
    46  readline
    47  sqlite
    48  webp
    49  xorgproto
    50  xz
    51  zstd

Relevant casks

graphviz, plantuml

[SMillerDev]

Question 1: What is/can be the reasons for this?

Dependencies can have dependencies of their own.

Question 2: Can I avoid this or separate part of this? I mean, if some of this is some "base stuff" in some way, can I have the script do that first or something... (The install took such a long time, it will cause problems.)

You could install the dependencies before you install graphviz. That would take the same time or longer in total, but it would allow you to run a shorter command multiple times instead of a single long one.

---

EDIT: MacPorts or any other package manager on Linux would likely have a similar problem since dependencies having subdependencies is a very common situation in software development.

[chipbite]

Thanks for the reply and clarifications - which confirms the situation for me. I have searched high and low for a "shortcut", but I guess I'll have to just resolve to inform the users about the a bit longer installation and clarify it as a separate step. Too bad the plantuml people havent done the "graphviz lite" package for macos (yet?) - have added a suggestion with plantuml.

Thanks.

[carlocab]

FYI, plantuml embedding a version of graphviz in the jar may not necessarily change anything for Homebrew users (and may just complicate our packaging of plantuml). See https://docs.brew.sh/Acceptable-Formulae#stuff-that-requires-vendored-versions-of-homebrew-formulae.

[chipbite]

@carlocab - not completely following. Offering alternative builds with embedded dependencies is a common approach in many situations in our wonderful world of computing, and offers choice and simplicity for users. In this case, it is done by plantuml project and only available for winos, it is not available for macos. I am not sure why any specific library builds should be more or less complicated for users of a certain package manager.

may not necessarily change anything for Homebrew users

If the plantuml embedding was also implemented for macos, why and how would homebrew affect macos users from using that .jar version so that it "does not change anything"? I must be misunderstanding you here, I am thinking it would simply change things by offering the macos users choice - the same choice winos users have already - of using a plantuml build with embedded dependency or not. Depending on their needs.

may just complicate our packaging of plantuml

Why? They are two different builds. Two different packages that are built and published. So, currently - again for winos only - you can select to download a jar without the graphviz code embedded or a jar with the code embedded. They serve different use cases. Not all users need graphviz for other uses, but some do.

But; I think this is rather hypothetical, since I am not sure how feasible it is implementing this for macos at all. We'll see what the project replies!

Btw, if you want to know more details, I have provided two links to more info, in the plantuml ticket I linked to above. Thanks for your thoughts!