Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Many rule have string argument when they should be label #10617

Closed
guibou opened this issue Jan 19, 2020 · 3 comments
Closed

Many rule have string argument when they should be label #10617

guibou opened this issue Jan 19, 2020 · 3 comments
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@guibou
Copy link
Contributor

guibou commented Jan 19, 2020

Description of the problem / feature request:

Many rules have string argument for things which, from my point of view, must be label.

For example, http_archive contains a patch_tool argument, which is a string and can be filled with the path to a patch binary. However, I'm building my patch binary using an external bazel repository, so I don't know beforehand the path for my patch binary. If patch_tool was accepting a label, I may just set it to @mypatch//:bin/patch for example.

I already opened a bug report for some specific rules here: #8438, but this bug report tries to be more general.

Feature requests: what underlying problem are you trying to solve with this feature?

I'm trying to have a fully reproducible build environment which does not depend on anything on the user system. To do that, I'm building / fetching everything in bazel, from simple tools such as patch to complex things such as CC toolchain. Unfortunately, a lot of rule in bazel expect string with the (absolute) path to utilities on the system, so that's technically non possible.

My current solution is to break a few bazel assumption and force my external repository rules to produce output in directories that I manage. Hence, I know beforehand the static path of my utilities.

The solution I'd like either:

  • Allows label everywhere string are allowed, and simply replace them by the path to the label
  • Allows $(location) (or similar invocation) in string argument for most rules.

What operating system are you running Bazel on?

Linux, macos and windows.

What's the output of bazel info release?

All bazel version are impacted.

Have you found anything relevant by searching the web?

no

Any other information, logs, or outputs that you want to share?

@laurentlb
Copy link
Contributor

Thanks for the feedback.
To clarify the request, I think it's mostly about repository functions.

In Starlark rules, I think the API is more consistent about the types.

@laurentlb laurentlb added team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website and removed team-Starlark labels Oct 9, 2020
@philwo philwo added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. P3 We're not considering working on this, but happy to review a PR. (No assignee) type: feature request and removed untriaged labels Dec 9, 2020
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
@github-actions
Copy link

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label May 24, 2023
@github-actions
Copy link

github-actions bot commented Jun 7, 2023

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P3 We're not considering working on this, but happy to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Development

No branches or pull requests

4 participants