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.

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 deprecation notice to aliases generated with import_alias naming convention #1048

Closed
tanyabouman opened this issue May 19, 2021 · 1 comment

Comments

@tanyabouman
Copy link
Contributor

What version of gazelle are you using?

0.22

What version of rules_go are you using?

0.25

What version of Bazel are you using?

4.0.0

Does this issue reproduce with the latest releases of all the above?

yes

What did you do?

Run Gazelle in a project with the # gazelle:go_naming_convention import_alias directive. Build one of the alias targets with the old go naming convention, named go_default_library.

What did you expect to see?

A warning message that go_default_library is deprecated.
For example:

WARNING: [path-to-build-file]/BUILD: target '//[libName]:go_default_library' is deprecated: Use :[libName] instead of :go_default_library.  Details about the new naming convention: https://github.com/bazelbuild/bazel-gazelle/pull/863

Since the go_default_library target might eventually be removed, it would be nice to give a warning. This can be easily done by adding a line in maybeGenerateAlias

alias.SetAttr("deprecation", "Use :"+libName+" instead of :go_default_library.  Details about the new naming convention: https://github.com/bazelbuild/bazel-gazelle/pull/863")

What did you see instead?

No warning about the deprecation.

@jayconrod
Copy link
Contributor

I don't think it makes sense for Gazelle to add deprecation notices to these aliases, especially by default.

go_repository uses generates build files with the import_alias naming convention by default. The targets it generates aren't really deprecated; many people likely still use them, and it doesn't really cost anything for them to be there.

For alias targets maintained within a repo for dependent targets in that repo, I would think labels referencing aliases could be updated fairly easily with Gazelle or Buildozer. If not, Buildozer could add deprecation attributes.

For alias targets maintained for dependent targets in other repos, deprecation may make sense, but I think it's fine to leave them as-is, too. Again, Buildozer can add deprecation attributes if you need them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants