Base again mistakes test deps for build/lib deps and creates a bogus dependency cycle

[barracuda156]

I think we are back to circular dependencies in R ports due to test dependencies being mistakes as build/lib dependencies.

2024-04-17T11:33:42.3412820Z Error: The following dependencies were not installed because all of them have unmet dependencies (likely due to a dependency cycle): R-bench R-DiagrammeR R-dplyr R-ggplot2 R-nycflights13 R-testthat R-tidyr R-tibble R-readr R-vroom R-waldo R-rematch2
2024-04-17T11:33:42.5387750Z Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
2024-04-17T11:33:42.5388420Z Error: Processing of port R-tibble failed
2024-04-17T11:33:42.5483220Z Testing 'R-tibble' failed.

[jmroot (Joshua Root)]

Testing 'R-tibble' failed.

You're running the test target, why would test dependencies not be installed?

[jmroot (Joshua Root)]

And I can't reproduce this anyway.

% sudo port -y test R-tibble
Password:
--->  Computing dependencies for R-tibble
--->  Dependencies to be installed: clang-15 R R-fansi R-lifecycle R-magrittr R-pillar R-pkgconfig R-rlang R-vctrs R-CRAN-recommended libomp llvm-15 clang_select cctools ld64 xar llvm_select ld64-xcode less gzip zip gnutar libgcc12 cairo pango glib2 fontconfig xorg-libsm xorg-libice xorg-libX11 xorg-libXt libpixman xrender xorg-libXext xorg-xcb-util xorg-xorgproto xorg-libxcb xorg-libXau xorg-libXdmcp xorg-xcb-proto fribidi harfbuzz Xft2 graphite2 gobject-introspection py312-mako py312-markdown py312-markupsafe libelf ossp-uuid R-cli R-glue R-utf8 R-boot R-class R-cluster R-codetools R-foreign R-KernSmooth R-lattice R-MASS R-Matrix R-mgcv R-nlme R-nnet R-rpart R-spatial R-survival
For libomp: skipping org.macports.main (dry run)
…

[jmroot (Joshua Root)]

I take it you were seeing this in the PR that just got committed, which is rather critical information that you omitted from the ticket. But there's still nothing wrong with the dependency calculation. For example R-tibble's test dependency R-bench has R-tibble in depends_lib, so the circular dep is real.

[barracuda156]

Replying to jmroot:

I take it you were seeing this in the PR that just got committed, which is rather critical information that you omitted from the ticket. But there's still nothing wrong with the dependency calculation. For example R-tibble's test dependency R-bench has R-tibble in depends_lib, so the circular dep is real.

How is this a circular dependency? Test dependencies should not be considered here. Macports is just wrong. I real dependency cycle makes installation impossible. Here it is not at all the case. In a given example, assuming neither is installed, and I invoke sudo port test R-tibble, the following should happen:

1. R-tibble gets installed.
2. R-bench is installed.
3. R-tibble tests are run.

There is no problem at all in this process with dependencies. It was broken at some point, then fixed, and then recently broken again by some change in the base.

[barracuda156]

The current setup forces to introduce tests variants for multiple ports as a hack to get around an issue which should just be fixed in the base.

[jmroot (Joshua Root)]

Dependency calculation has never worked that way in MacPorts, but if you believe otherwise you need only bisect and find the commit where it regressed.

[barracuda156]

Replying to jmroot:

Dependency calculation has never worked that way in MacPorts, but if you believe otherwise you need only bisect and find the commit where it regressed.

You indeed know better how it worked technically, but from the user-side it worked correctly earlier and stopped working very recently. If it was not so, many R-related updates would have kept failing at CI, since it is pretty common situation when a lib dependency of one port has that very port as a test dependency.

I also think this was discussed earlier already, and I think it was fixed.

I will try to find what broke it, when I get time to.