Comments (6)
Not sure if this is the issue you're reporting, but I'll share what I just got working. Bazel Version 7.0.0rc1 (if that matters).
# MODULE.bazel
bazel_dep(name = "gazelle", version = "0.35.0", repo_name = "bazel_gazelle")
bazel_dep(name = "rules_go", version = "0.44.2", repo_name = "io_bazel_rules_go")
# (etc)
then
# BUILD.bazel
load("@bazel_gazelle//:def.bzl", "gazelle")
gazelle(
name = "gazelle-update-repos",
args = [
"-from_file=go.work",
"-to_macro=go_deps.bzl%go_deps",
"-prune=True",
],
command = "update-repos",
)
This is the only part that feels suboptimal:
# WORKSPACE.bazel
load("//:go_deps.bzl", "go_deps")
go_deps()
from bazel-gazelle.
Relevant slack thread: https://bazelbuild.slack.com/archives/C014RARENH0/p1704836682274409?thread_ts=1700623974.089569&cid=C014RARENH0
from bazel-gazelle.
This is supposedly already supported:
#1250
from bazel-gazelle.
I've been exploring and prototyping go.work via bzlmod over here. We are using this approach as a prototype at work, and it's working without issue.
Example in a tiny OSS go.work repo
https://github.com/stefanpenner/_bzlmod_go_work/blob/4c5ea1e6fd083ff20ada293056407bdf0919b55d/MODULE.bazel#L18-L19
A nice part of this, is no gazelle-update-repos
is required.
One known caveat: all go dependencies in the workspace are visible to all go modules, even if a given module does not include it in its go.mod file. If users diligently run go mod tidy
, no issues will arise, but if they do not, they may end up in a scenario where a build would pass with bazel but fail with native tooling. This would be a problem if the intent is for someone to consume the module in question as an external dependency.
On a positive note, their IDE should also tell them the problem exists. But CI would pass, and it really shouldn't.
@fmeum gave some suggestions, and I hope to explore them shortly.
- use visibility to emulate dependency scoping
- use gazelle to ensure
@sluongng also gave some suggestions with regards to avoiding relying on go.work.sum
which I hope to also explore
from bazel-gazelle.
use visibility to emulate dependency scoping
I explored this, and although possible it seems a little funky, and I would love input:
- calculate the inter go module visibility graph
- ensure each go module is represented by a single package_group, lets say
@repo/package-name:package_group
. This helps simplify the values we place into visibility attributes. - target visibility attrs within a given go module must include:
- their own module package_group name (for interior visibility)
- all dependent go module package_group names
use gazelle to ensure
I've started this, but haven't completed this exploration yet.
from bazel-gazelle.
Relevant slack thread: https://bazelbuild.slack.com/archives/C014RARENH0/p1704836682274409?thread_ts=1700623974.089569&cid=C014RARENH0
Could you send me the invitation link of this slack? I can't find a usable one on the internet.
I'm currently using Bazel in my Go project and I may need some help to solve the problems.
from bazel-gazelle.
Related Issues (20)
- Use host module cache without build cache
- go_repository does not support fallback configured via GOPROXY environment variable HOT 1
- cahed bazel_gazelle_go_repository_tools does not rebuild when OS architecture changes HOT 3
- Transitive Go dependencies not included when using `go_deps.from_file` HOT 3
- Any way to conditionally apply module_overrides? HOT 6
- Gazelle gets confused if directories already contain both BUILD and .pb.go files
- Gazelle extremely slow with MODULE.bazel and kubernetes
- Tables in the documentation are difficult to read HOT 2
- Expose bazel_deps to go_deps extension HOT 1
- new gazelle v0.36.0 fails with Go sum mismatches HOT 10
- go.mod FilePath ReplaceDirective is missing when using the go-deps bzlmod extension HOT 1
- gazelle_binary fails nogo linting
- 'invalid use of internal package' in IDE in external tests HOT 4
- Failing to upgrade to gazelle 0.36 HOT 1
- Gazelle ignores several GIT_CONFIG environment variables
- Gazelle fails on macOS when using `apple_support` and go version 1.22+ HOT 7
- Cyclical Indirect Dependencies & Go.work can cause divergence HOT 1
- Add support for generated files in gazelle HOT 1
- Gazelle should extract module mappings from imported foo.MODULE.bazel files
- Passing debug_mode via go_deps to go_repository is not supported HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bazel-gazelle.