bazelbuild
Drop "Dependency adapters for virtual targets".
As discussed on #16380, the potential benefits given the alternatives of doing this in a FUSE (or NFS-as-FUSE on Mac OS) file system or teaching bazel query to recursively determine transitive dependencies and the difficulty of designing an interface that is simple enough, performant enough and stable enough is considerable.
As discussed on #16380, the potential benefits given the alternatives of doing this in a FUSE (or NFS-as-FUSE on Mac OS) file system or teaching bazel query to recursively determine transitive dependencies and the difficulty of designing an interface that is simple enough, performant enough and stable enough is considerable.
To be clear, I don't agree with these statements and they're not an accurate representation of why I decided to stop discussing upstreaming efforts. To quote my last comment in https://github.com/bazelbuild/bazel/issues/16380:
at the moment, we seem to have reached an impasse on the necessity and approach to this feature.
While I've accepted that you have no desire to properly support this use case (further evidenced by the fact that you closed the issue without addressing my ask to keep it open for others to discuss), please do not misrepresent my reasons for stepping away from that issue. I still fully believe that dependency resolution APIs (in one form or another) can be cleanly integrated into Bazel and that FUSE or "magicdeps()" are not acceptable replacements. However, the Bazel team has uniformly dismissed the underlying concerns that prompted the initial proposal, so any collaboration or integration with the upstream project is evidently a non-starter.
I am not interested in continuing this argument. I am simply asking that you do not conclude that the proposed alternatives provided a satisfactory resolution to the issue; they did not.
CC: @sluongng, @maxious, @linzhp
Actually, managed to skim over the half-sentence asking for the issue to be kept open and it makes total sense. Sorry about that. Bug reopened.
It's not an accurate representation of my point of view to say that I "dismissed the underlying concerns"; I am fully aware what limitations the alternatives I proposed have. But I am also aware of the limitations every design proposed on https://github.com/bazelbuild/bazel/issues/16380 has. And the better the alternatives are, the less motivation there is to continue the work on better alternatives because the maximum possible upside is limited by how bad the alternatives are.