Comments (12)
Here's a sketch of how I think this should work. I'd rather not review a more detailed design doc right now though.
- The
//language/go
extension should accept a directive,# gazelle:go_naming_convention
, that supports the values:go_default_library
- old style, what Gazelle currently does.import
- new style.- For a package whose import path ends with
foo
, thego_library
would be namedfoo
. Thego_test
would be namedfoo_test
. - For a main package, the
go_library
would be namedfoo_lib
, thego_test
would be namedfoo_test
, and thego_binary
would be namedfoo
. - Major version suffixes would be dropped from import paths for naming purposes. So a library with the path
example.com/foo/v2
would be namedfoo
, notv2
.
- For a package whose import path ends with
import_alias
- same asimport
but additionally generatesalias
rules mappinggo_default_library
targets toimport
targets.
- If the directive isn't specified anywhere,
//language/go
should attempt to automatically determine the naming convention currently in use by scanning build files one or two directories deep from the root. If it doesn't find anygo_library
rules conforming to one style or the other (as will be the case for a repository without any build files), it should use theimport
style. - The
Fix
method should rename rules as needed between the two styles. That should probably happen whether or notc.ShouldFix
is set, since there's explicit user intent here. go_repository
should have abuild_naming_convention
attribute, used to set this directive. It should default toimport_alias
.- External dependency resolution should respect the
build_naming_convention
attribute for known repositories. If the repository is unknown or if the attribute isn't set explicitly, it should follow the convention currently in use.
from bazel-gazelle.
at
//foo/bar
should be namedfoo
I think you meant to say: at //foo/bar
should be named bar
.
And cannot wait for this change to finally land.
from bazel-gazelle.
Correct. I've edited the original issue.
from bazel-gazelle.
Just wonder if there's any ETA when this would be fixed. Thanks!
from bazel-gazelle.
No ETA, sorry.
from bazel-gazelle.
This would need a major migration plan to become effective, right?
from bazel-gazelle.
@riking Yes
from bazel-gazelle.
Is there an active design document for this, or should one be drafted? Is there a consensus? I've read a few different assertions on how things should work that all seem to slightly contradict each other.
I'm rolling out gazelle to our monorepo, and the "go_default_library" everywhere can be a little grating on the eye.
from bazel-gazelle.
Sorry, this is annoying. I'm afraid there's no active plan to make this happen at the moment though. Other functional issues (editor support, coverage, proto support) still seem more important.
The problem is migration. A change to all rules will be really disruptive for large projects (and people have objected loudly to disruptions of this scale in the past). So this definitely needs to be opt-in for existing projects. At the same time, the new names should be used by default for new projects.
This is also difficult for repositories that are used as dependencies in other repositories. If they want to switch to the new names, they'd need to have aliases with the old names to avoid breaking their dependents. Gazelle should be able to generate those names.
from bazel-gazelle.
Would it be possible to draft the design without executing on it? I can create a design doc if you want. That way we know where we are headed. What I'd need is an initial summary of what you would like to see, plus a list of considerations similar to the above message.
We have our own little monorepo over here, and I am already half inclined to hack gazelle (which I tried yesterday for verification purposes) to produce better names before I start enforcing it via a glaze-style presubmit. It would be nice to know that the solution is compatible with the desired end state, and if desired I could contribute it behind said opt-in flag.
from bazel-gazelle.
EDIT: These questions were pretty much answered during implementation. Ignore the below.
For import
mode, what happens when the bazel package name and importpath differ?
Eg. package '//foo' with importpath 'bar'.
Should the go_library
be called foo
or bar
? (Similar question for the go_binary
)
from bazel-gazelle.
@linzhp @blico Just wanted to give you a heads up that @tomlu is working on a fix for this issue (#808).
The plan we're following is basically this comment above. Please let me know if there's something we're not anticipating though.
from bazel-gazelle.
Related Issues (20)
- `gazelle:go_test file` does not account for a test file calling a function in another, sibling test file HOT 6
- gazelle:default_visibility directive does not work properly HOT 2
- bug(bzlmod): go_deps overrides should fail with `path` that doesn't exist
- `findGoTool` uses the system Go when it should use the Go defined in the Bazel workspace
- feat(bzlmod): script to generate `go_deps.{}_override`s from `go_repository` rules in a `.bzl` file
- embedsrcs fails when downloading files with http_archive
- Bug: when the go code embedded a file that located in another package gazelle will ignore that file HOT 1
- `# gazelle:resolve` directives are very inefficient
- bug(cmd/gazelle): `:gazelle_test` is broken on Bzlmod HOT 1
- BUILD file not found in directory 'modfile' of external repository @org_golang_x_mod. HOT 4
- gazelle resolve directives not working
- idea: lang/go: generate BUILD files from `go build -x` output HOT 1
- go_deps extension doesn't generate indirect dependencies HOT 2
- gazelle generates and recreates grpc targets that rules_go complains about HOT 6
- Missing documentation and best practices for bzlmod HOT 9
- Support Golang Workspaces in Gazelle HOT 6
- gazelle 0.35.0 panics HOT 4
- #gazelle:proto file” directive isn’t usable unless option go_package is explicitly set in each proto_library HOT 18
- Error in fail: failed to fetch com_github_gorilla_mux: go: missing Git command.
- Gazelle requires WORKSPACE when using update-repos in a bzlmod only repo HOT 4
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.