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.

Sign up for GitHub

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

Jump to bottom

Allow module extensions to fail on a tag #17375

Closed
fmeum opened this issue Feb 1, 2023 · 3 comments
Closed

Allow module extensions to fail on a tag #17375

fmeum opened this issue Feb 1, 2023 · 3 comments
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request

Comments

@fmeum
Copy link
Collaborator

fmeum commented Feb 1, 2023

Description of the feature request:

Module extensions should be able to fail on a particular module extension tag so that the emitted stack trace points to the location at which the particular tag was created by the user.

What underlying problem are you trying to solve with this feature?

When a user specifies an invalid module extension tag in their MODULE.bazel file (e.g. a version of a dependency that isn't valid) and the module extensions fails due to that, the stack trace starts with the module extension implementation function. There is no way to reference the particular tag that caused the failure, which makes it unnecessarily difficult for the user to fix the issue.

Which operating system are you running Bazel on?

Any

What is the output of bazel info release?

6.0.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

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

No response
@ShreeM01 ShreeM01 added type: feature request team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. untriaged labels Feb 1, 2023
@Wyverald Wyverald added P2 We'll consider working on this in future. (Assignee optional) area-Bzlmod Bzlmod-specific PRs, issues, and feature requests and removed untriaged labels Mar 9, 2023
@fmeum fmeum mentioned this issue Mar 27, 2023
Closed
@fmeum fmeum mentioned this issue Jun 29, 2023
Closed
copybara-service bot pushed a commit that referenced this issue Aug 17, 2023
@fmeum @tetromino @copybara-github
Use debugPrint instead of str for fail arguments
3abbf20 
This allows non-hermetic information (such as Starlark `Location`s) to be included in `fail` messages without allowing access to it from Starlark. It also aligns the content of `fail` output with that of `print`.

This change has very mild implications for backwards compatibility: it only affects the contents of `fail` messages, which aren't accessible from Starlark; `debugPrint`'s default implementation is `str` and no built-in Starlark type overrides it; if a type overrides `debugPrint`, it would usually contain at least as detailed information as `str`; `debugPrint` is a "Bazelism" that isn't governed by the Starlark spec.

Work towards #17375

Closes #18818.

Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
PiperOrigin-RevId: 557916312
Change-Id: I8f202cd8530bcebb2d99f57745289b3992d03cac
@bazel-io bazel-io mentioned this issue Aug 18, 2023
Merged
bazel-io pushed a commit to bazel-io/bazel that referenced this issue Aug 18, 2023
@fmeum @tetromino @bazel-io
Use debugPrint instead of str for fail arguments
247ce0c 
This allows non-hermetic information (such as Starlark `Location`s) to be included in `fail` messages without allowing access to it from Starlark. It also aligns the content of `fail` output with that of `print`.

This change has very mild implications for backwards compatibility: it only affects the contents of `fail` messages, which aren't accessible from Starlark; `debugPrint`'s default implementation is `str` and no built-in Starlark type overrides it; if a type overrides `debugPrint`, it would usually contain at least as detailed information as `str`; `debugPrint` is a "Bazelism" that isn't governed by the Starlark spec.

Work towards bazelbuild#17375

Closes bazelbuild#18818.

Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
PiperOrigin-RevId: 557916312
Change-Id: I8f202cd8530bcebb2d99f57745289b3992d03cac
iancha1992 pushed a commit that referenced this issue Aug 18, 2023
@bazel-io @fmeum @tetromino
[6.4.0] Use debugPrint instead of str for fail arguments (#19283)
b2054d6 
This allows non-hermetic information (such as Starlark `Location`s) to
be included in `fail` messages without allowing access to it from
Starlark. It also aligns the content of `fail` output with that of
`print`.

This change has very mild implications for backwards compatibility: it
only affects the contents of `fail` messages, which aren't accessible
from Starlark; `debugPrint`'s default implementation is `str` and no
built-in Starlark type overrides it; if a type overrides `debugPrint`,
it would usually contain at least as detailed information as `str`;
`debugPrint` is a "Bazelism" that isn't governed by the Starlark spec.

Work towards #17375

Closes #18818.

Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
Commit
3abbf20

PiperOrigin-RevId: 557916312
Change-Id: I8f202cd8530bcebb2d99f57745289b3992d03cac

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
Co-authored-by: Alexandre Rostovtsev <arostovtsev@google.com>
@meteorcloudy
Copy link
Member

@fmeum Is this already fixed?

@fmeum
Copy link
Collaborator Author

fmeum commented Sep 7, 2023

@meteorcloudy Yes, it was fixed in #19274.

@fmeum fmeum closed this as completed Sep 7, 2023
@iancha1992
Copy link
Member

A fix for this issue has been included in Bazel 6.4.0 RC1. Please test out the release candidate and report any issues as soon as possible. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-Bzlmod Bzlmod-specific PRs, issues, and feature requests P2 We'll consider working on this in future. (Assignee optional) team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. type: feature request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add causes parameter to fail and use it for extension tags fmeum/bazel
5 participants
@Wyverald @meteorcloudy @fmeum @ShreeM01 @iancha1992