-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Add --enable_workspace
flag (defaulting to true) to allow turning off WORKSPACE logic
#20185
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
Milestone
Comments
@bazel-io fork 7.1.0 |
Wyverald
added a commit
that referenced
this issue
Jan 11, 2024
… handling * This flag defaults to true * When turned off (`--noenable_workspace`), no WORKSPACE file reading is ever done (including `WORKSPACE.bzlmod`, `WORKSPACE.resolved`, prefixes, suffixes, etc). No `//external` package is created or used. * Bzlmod and WORKSPACE can't both be turned off. * We no longer mandate that a WORKSPACE file has to be at the root of a repo; that is now replaced by `REPO.bazel`. But it's still okay to have a `WORKSPACE` file and no `REPO.bazel` file at the root of a `local_repository`, for example. * All Bzlmod integration tests now have `--noenable_workspace` set. Fixes #20185. RELNOTES: Added a flag `--enable_workspace` (defaults to True) that allows the user to completely disable WORKSPACE logic when turned off. PiperOrigin-RevId: 589978780 Change-Id: I07a1b8674aaad2758ded57c3a48dba2a19c91e04
Wyverald
added a commit
that referenced
this issue
Jan 11, 2024
… handling * This flag defaults to true * When turned off (`--noenable_workspace`), no WORKSPACE file reading is ever done (including `WORKSPACE.bzlmod`, `WORKSPACE.resolved`, prefixes, suffixes, etc). No `//external` package is created or used. * Bzlmod and WORKSPACE can't both be turned off. * We no longer mandate that a WORKSPACE file has to be at the root of a repo; that is now replaced by `REPO.bazel`. But it's still okay to have a `WORKSPACE` file and no `REPO.bazel` file at the root of a `local_repository`, for example. * All Bzlmod integration tests now have `--noenable_workspace` set. Fixes #20185. RELNOTES: Added a flag `--enable_workspace` (defaults to True) that allows the user to completely disable WORKSPACE logic when turned off. PiperOrigin-RevId: 589978780 Change-Id: I07a1b8674aaad2758ded57c3a48dba2a19c91e04
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 11, 2024
…ORKSPACE… (#20855) … handling * This flag defaults to true * When turned off (`--noenable_workspace`), no WORKSPACE file reading is ever done (including `WORKSPACE.bzlmod`, `WORKSPACE.resolved`, prefixes, suffixes, etc). No `//external` package is created or used. * Bzlmod and WORKSPACE can't both be turned off. * We no longer mandate that a WORKSPACE file has to be at the root of a repo; that is now replaced by `REPO.bazel`. But it's still okay to have a `WORKSPACE` file and no `REPO.bazel` file at the root of a `local_repository`, for example. * All Bzlmod integration tests now have `--noenable_workspace` set. Fixes #20185. RELNOTES: Added a flag `--enable_workspace` (defaults to True) that allows the user to completely disable WORKSPACE logic when turned off. PiperOrigin-RevId: 589978780 Change-Id: I07a1b8674aaad2758ded57c3a48dba2a19c91e04
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
Setting this flag to false should turn off all WORKSPACE related logic, including evaluating the WORKSPACE/WORKSPACE.bazel/WORKSPACE.bzlmod files at all, any WORKSPACE prefixes/suffixes, the
LocalRepositoryLookupFunction
(with some sort of replacement).A blocker for this issue would be #18285; we currently still don't have a way to specify a
local_repository
/new_local_repository
in a module extension.The text was updated successfully, but these errors were encountered: