Pulls in gazelle_dependencies

[pauldraper]

container_deps() pulls in gazelle_dependencies() which is badly behaved.

Namely, it fails if a file named "WORKSPACE" does not exist: bazelbuild/bazel-gazelle#678

But AFAIK I shouldn't need gazelle anyway, am I correct?

[agutkin]

I second this question.

[UebelAndre]

If you suspect the dependencies are not needed, I'd say make a PR 😄. The maintainers here are not actively contributing to the rules but seem to be providing review support. I've made similar PRs to remove unneeded python dependencies so I think a change like this would have no issues as well.

[pauldraper]

The maintainers here are not actively contributing to the rules

?!?!? rules_docker is in maintenance mode ?!?!?

[UebelAndre]

The maintainers here are not actively contributing to the rules

?!?!? rules_docker is in maintenance mode ?!?!?

Sorry, that's not what I meant at all.

From what I've gathered from an external contributor, the maintainers here are also maintainers on other projects and in recent months, there has been less activity here and more activity on those projects. I cannot speak to the state of rules_docker, this was a personal observation.

I was more trying to say, "if this is a real issue, you should open a PR and will likely get a reviewer in a timely manner". This was my experience on prior PRs.

[ownbee]

If I've understood it correctly the the docker rules are using golang code to build the layers and images. That go code have dependencies which is why gazelle "is needed".

We have a policy to cache all external resources in my company since we don't want to pull from external servers on hundreds of computers. My team would love to use this repo but we are not using golang at all so we have no golang-cache which makes it hard to motivate usage of this repo... I also heavily dislike having to bring in a golang compiler and tooling when I don't need it for any target code since that brings complexity and maintenance of a language I never use.

Other rules repositories releases pre-built tools which other projects automatically pull when setting up the rules, without the need to build them (and pull lots of extra deps). That could be a solution for this repo and I would be happy to help contribute but I have not done such thing before...

EDIT:
It seem like some go tools are delivered pre-built but not all? Anyone knows if there is ongoing work?

[alexeagle]

We are working on distributing the go binaries so there's no Go/gazelle dependency exposed to users. Starting with puller/pusher

[UebelAndre]

Are there tracking issues for each binary? I'm not super familiar with all the things in rules_docker

[alexeagle]

No, sorry no tracking issues, and after starting the investigation I'm not sure cutting our rules_go or bazel_gazelle dependencies would work very well. That was a bit off-topic here anyhow...

To answer the question, yeah we do require you to have bazel_gazelle currently, because we use the go_repository rule to fetch third-party deps for all the binaries you must build from source, such as the digester used to create any layers.
https://github.com/bazelbuild/rules_docker/blob/master/repositories/go_repositories.bzl#L22
It's installed when you call container_repositories
https://github.com/bazelbuild/rules_docker/blob/master/repositories/repositories.bzl#L178-L183
but that's an old version.

The workaround is to install your own bazel_gazelle at a newer version.

[alexeagle]

@pcj any updates here on your changes to the puller/pusher build so that users don't need to have gazelle running?

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[UebelAndre]

This is an issue that should still be addressed. Users shouldn't be required to pull in large dependencies if it can can be avoided.

[abhillman]

FWIW this issue is related to #1093 (comment). In that example, removing container_deps() clears up the issue.

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days.
Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_docker!

[github-actions]

This issue was automatically closed because it went 30 days without a reply since it was labeled "Can Close?"