[workspace] Elevate drake_models to public visibility

[jwnimmer-tri]

Towards #15774.

Towards #19094 -- this fixes the drake_bazel_installed but not rules_python.

(Sorry, I know this is like the third time I've rewritten this code in the past two weeks.)

---

This change is 

[jwnimmer-tri]

+@rpoyner-tri for feature review, please. (We'll tap Xuchen for platform after feature is done.)

[rpoyner-tri]

Moderate regret for statically listing all the files, but I realize that's probably the right interface for a public dependency.

Reviewed 29 of 29 files at r1, all commit messages.
Reviewable status: needs at least two assigned reviewers (waiting on @jwnimmer-tri)

[jwnimmer-tri]

+@xuchenhan-tri for platform review per schedule, please.

[xuchenhan-tri]

platform

Moderate regret for statically listing all the files, but I realize that's probably the right interface for a public dependency.

Can someone explain why statically listing all files is better than globbing everything in a directory, even when the list is tediously long?

Reviewed 29 of 29 files at r1, all commit messages.
Reviewable status: 1 unresolved discussion (waiting on @jwnimmer-tri)

---

-- commits line 10 at r1:
BTW, what about non-bazel workflows. When does model downloading for those happen?

Code quote:

  Enhance the drake_bazel_installed workflow to provide drake_models as
  an external repository to avoid extra downloading at runtime.

[jwnimmer-tri]

Can someone explain why statically listing all files is better than globbing everything in a directory, ...

You can only glob within your own bazel package, i.e., where your BUILD.bazel file lives. Trying to glob someone else's package is an error.

... even when the list is tediously long?

Hah. This is nothing. Personally, I think listing out a dozen files when writing an example program is way easier than trying to debug why someone's glob() has gone awry and not found what they wanted it to find. BUILD files should be direct and explicit, for clarity.

Reviewable status: 1 unresolved discussion (waiting on @xuchenhan-tri)

---

-- commits line 10 at r1:

Previously, xuchenhan-tri wrote…

BTW, what about non-bazel workflows. When does model downloading for those happen?

When building Drake from source via Bazel (e.g., in Anzu), the model downloading happens via repository rules at "bazel fetch" time (which itself happens implicitly as part of "bazel build"). Our C++ code never downloads anything in this case.

In most other cases, package://drake_models is downloaded on demand the first time someone calls package_map.GetPath("drake_models"), and then cached for future use so there are no more downloads (of that git version pin). This is what happens for apt or pip users -- the download cached into their $HOME/.cache directory or alike.

The problem this PR solves (in part) is when someone is using a Drake binary release but doing it via Bazel. In that case, tests cannot write to $HOME/.cache (because of sandboxing) so even though the download happens and the test passes, there is no caching so it's downloaded over and over again, for any test that happens to use those models. We solve it here for anyone using the drake_bazel_external pattern from drake-external-examples. What still remains to be solved is how to solve it for drake binary + bazel users who are not using that ruleset (e.g., if they are using rules_python with pip instead).

[xuchenhan-tri]

You can only glob within your own bazel package, i.e., where your BUILD.bazel file lives. Trying to glob someone else's package is an error.

Thanks for the reference. Is it possible for the model directory to glob the mtl/obj/other files and export them for easy consumption of the drake BUILD file?

Reviewable status: complete! all discussions resolved, LGTM from assignees rpoyner-tri(platform),xuchenhan-tri(platform) (waiting on @jwnimmer-tri)

---

-- commits line 10 at r1:

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

When building Drake from source via Bazel (e.g., in Anzu), the model downloading happens via repository rules at "bazel fetch" time (which itself happens implicitly as part of "bazel build"). Our C++ code never downloads anything in this case.

In most other cases, package://drake_models is downloaded on demand the first time someone calls package_map.GetPath("drake_models"), and then cached for future use so there are no more downloads (of that git version pin). This is what happens for apt or pip users -- the download cached into their $HOME/.cache directory or alike.

The problem this PR solves (in part) is when someone is using a Drake binary release but doing it via Bazel. In that case, tests cannot write to $HOME/.cache (because of sandboxing) so even though the download happens and the test passes, there is no caching so it's downloaded over and over again, for any test that happens to use those models. We solve it here for anyone using the drake_bazel_external pattern from drake-external-examples. What still remains to be solved is how to solve it for drake binary + bazel users who are not using that ruleset (e.g., if they are using rules_python with pip instead).

The explanation is very helpful. Thank you!

[jwnimmer-tri]

Is it possible for the model directory to glob the mtl/obj/other files and export them for easy consumption of the drake BUILD file?

Yes it's possible in Bazel in general, but I am purposefully avoiding it. The design I am aiming for is that drake_models will be like a ROS package. As such, it will not have a BUILD file and will not provide any filegroup shortcuts.