Flip --enable_workspace to false

[meteorcloudy]

Motivation

Disabling WORKSPACE by default is the next step towards migrating the Bazel ecosystem to Bzlmod for managing external dependencies.

Benefits of Bzlmod over WORKSPACE:

• Automatic MVS-based Bazel module dependency resolution
• No need to declare transitive dependencies
• Better integration with third-party package managers with module extension
• Repo level visibility control
• Easy to inspect dependency graph with bazel mod
• Support for lockfile, vendor/offline mode

We plan to remove this flag and the entire WORKSPACE logic in Bazel 9.

For more information, check https://bazel.build/external/overview

Description

With --enable_workspace defaults to false, the WORKSPACE file is no longer needed and does not take any effect in a Bazel project.

You should expect the following breaking behaviours:

• The root of a Bazel repo is no longer marked by WORKSPACE, but by MODULE.bazel (or REPO.bazel).
• External dependencies defined in WORKSPACE are no longer effective. You may start to see errors like "unknown repo 'foo' requested from @@".
• Toolchains/platforms registered in WORKSPACE are no longer effective
• Bind statement (already deprecated) are no longer effective

If all your external dependencies have migrated to Bzlmod, WORSPACE and WORKSPACE.bzlmod files can be safely deleted. Otherwise, you can temporarily enable WORKSPACE via --enable_workspace=true.

Incompatible Flag

--noenable_workspace

Migration Guide

Please refer to https://bazel.build/external/migration on how to migrate from WORKSPACE to Bzlmod.

We'll continue to improve the migration guide on common issues and best practices, PRs from the community are also welcomed!

And please feel free to report issues that are blocking your migration.

In which Bazel LTS version will this incompatible change be enabled?

Bazel 8

Additional Context

No response

TODO List

• Implement the incompatible change at Bazel HEAD and guard it behind a flag.
• Backport the incompatible flag to the latest LTS release (Flag is available in the latest minor release of Bazel 7, default to true).
• Make sure output meaningful error messages when WORKSPACE is disabled.
• Test the incompatible change with downstream projects and inform broken projects.
  • https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/4009
• Migrate Bazel's own test suites off WORKSPACE. (All broken tests)
  • Python integration tests: Disable WORKSPACE in python integration tests #23034
  • Java integration tests: Disable WORKSPACE in java integration tests #23086
  • Shell integration tests: WIP: disable WORKSPACE in shell integration tests #23087
  • Java unit tests: WIP: Flip --enable_workspace to false #23253
• Flip the incompatible flag at Bazel HEAD.
• Fix some Bzlmod bugs discovered.
• Delete the incompatible flag and the old behavior at Bazel HEAD.

[Wyverald]

I was daydreaming a bit about what we could do after 8.0 is cut:

1. Delete a whole bunch of code related to the WORKSPACE file.
   • Immediately, this means WorkspaceFileFunction, WorkspaceFactory, WorkspaceFactoryHelper, WorkspaceGlobals, all "resolved file" stuff, etc.
   • Further things that can be deleted: WorkspaceNameFunction (can be turned into a constant), BzlLoadFunction.KeyForWorkspace, ExternalPackageFunction, ExternalPackageHelper, the bit in PackageFunction that deals with the //external package (in fact, the entire //external package is gone), etc.
   • Also includes all the things in Package that only apply to the "external" package -- registered toolchains, exec platforms, "map of repo mappings for each given repo", "workspace name" (again, just a constant now), etc.
2. Delete all native repo rules.
   • This requires hardcoding @bazel_tools in RepositoryDelegatorFunction as a symlink, which in turn requires a crapton of unit test fixes... Still working on that.
   • This would unblock merging StarlarkRepositoryFunction into RepositoryFunction, and potentially further merging with RepositoryDelegatorFunction -- which in turn would unblock some refactoring to get rid of awkward code structuring introduced with the worker thread stuff (because only StarlarkRepositoryFunction could use worker threads).
3. Then, repo rules can stop using the Rule/RuleClass machinery intended for build rules.
   • A repository_rule can just be represented by a RepoRule class (instead of today's RuleClass). A ready-to-fetch repo can just be a Repo (instead of Rule). RepoSpec will remain the "dehydrated" Repo.
4. Remove some Bzlmod-centric logic that nevertheless had to deal with WORKSPACE.
   • RepositoryMapping can no longer "fall back"; RepositoryMappingFunction can remove swaths of WORKSPACE handling (including the composition); RepositoryMappingValue.Key can lose the "main repo can see workspace" bit.
   • The list of "well-known modules" can be pared down to just bazel_tools.

Clock's ticking... rubs hands

[meteorcloudy]

All look very attractive! I just have one small concern: all those changes are technically breaking changes and major refactors, so we're not going to backport them to Bazel 8. That means any further improvement to the external dependency system (e.g. shared repo cache) might be harder to backport due to diverged code. But I guess the benefits of removing WORKSPACE still outweighs the trouble it might cause for backporing.

[fmeum]

We might want to remove the code closer to Bazel 9 to facilitate cherry-picks into Bazel 8.

[meteorcloudy]

Yeah, I think we can try to plan and estimate what kind of major changes we still want to make and backport, then decide when is a good time to start removing WORKSPACE from HEAD.