Skip to content

Add go_binary out attribute for custom file names#1393

Merged
jayconrod merged 1 commit intobazel-contrib:masterfrom
jayconrod:go-binary-out
Mar 21, 2018
Merged

Add go_binary out attribute for custom file names#1393
jayconrod merged 1 commit intobazel-contrib:masterfrom
jayconrod:go-binary-out

Conversation

@jayconrod
Copy link
Collaborator

go_binary now has an "out" attribute which allows users to set the
output filename for the generated executable. When set, go_binary will
write this file without mode-specific directory prefixes, without
linkmode-specific prefixes, and without platform-specific extensions.

Fixes #1239

go_binary now has an "out" attribute which allows users to set the
output filename for the generated executable. When set, go_binary will
write this file without mode-specific directory prefixes, without
linkmode-specific prefixes, and without platform-specific extensions.

Fixes bazel-contrib#1239
@jmillikin-stripe
Copy link
Contributor

How is this different from the basename attribute? Does it replace it?

@jayconrod
Copy link
Collaborator Author

basename lets you use a custom stem instead of the rule name, but the binary will still be written into a mode-specific prefix directory, and the final file name may have prefixes and extensions like lib or .exe.

out lets you completely specify the output file name.

I don't think this completely replaces basename, but I probably wouldn't add basename if we already had out.

@jmillikin-stripe
Copy link
Contributor

It seems pretty awkward to have executables on Windows written without .exe, unless each user of this new param sets up appropriate select calls for all the platforms that might need a suffix on binaries. Are there any examples of when a user might want to create a binary without a suffix?

I guess I don't understand why any value of out other than attr.name would be useful. Maybe it'd be good to add an example or two of how this would be used?

@jayconrod
Copy link
Collaborator Author

So just to throw out a random example, files in Linux /lib directories are supposed to be named with a version after the extension, e.g., libfoo.so.1.2.3. basename = "foo" would just give us libfoo.so without the version. If out added an extension, you'd get libfoo.so.1.2.3.so.

out is a general purpose escape hatch for when our naming scheme doesn't work. I don't expect it to be commonly used, but when it's needed, we should let users do exactly what they want with it.

@jmillikin-stripe
Copy link
Contributor

jmillikin-stripe commented Mar 20, 2018

Isn't the version usually part of the pre-suffix name? Looking at my /lib and /usr/lib I see names like libc-2.23.so, libdb-5.3.so , libelf-0.165.so that have symlinks pointing at them with names like libc.so.6.

Also, the general-purpose escape hatch is genrule with a copy.

@ianthehat
Copy link
Contributor

basename was meant as an escape hatch, but it's not really sufficient for any useful case, we should probably deprecate it's use.
out lets you specify anything you like, if it still did anything automatically that would not be true, and we would be back having this conversation again with someone else that wanted different behaviour.

@jayconrod jayconrod merged commit 361556b into bazel-contrib:master Mar 21, 2018
@jayconrod jayconrod deleted the go-binary-out branch March 21, 2018 14:42
wking added a commit to wking/openshift-installer that referenced this pull request Jul 6, 2018
The most recent issue was bazel-contrib/rules_go#1393, which landed on
March 21st [1].  That code went out with rules_go v0.11.0:

  rules_go$ git log --oneline -1 361556b
  361556b Add go_binary out attribute for custom file names (openshift#1393)
  rules_go$ git describe --contains 361556b
  0.11.0~26

I'm bumping to 0.12.1 as the most-recent tagged release [2] (although
0.13.0 was cut two days ago, and seems to just be missing a tag [3]).

While I'm at it, I've bumped bazel-gazelle to it's most-recent tagged
release [4].  I'm not sure if the Bazel libraries are compatible
between minor releases, but they seem to be versioned together so
having 0.12.x versions of both seemed safest.

[1]: bazel-contrib/rules_go#1393 (comment)
[2]: https://github.com/bazelbuild/rules_go/releases
[3]: bazel-contrib/rules_go#1584 (comment)
[4]: https://github.com/bazelbuild/bazel-gazelle/releases
yushan26 pushed a commit to yushan26/rules_go that referenced this pull request Jun 16, 2025
Before that the users had to rely on patching the actual wheel files and
uploading them as different versions to internal artifact stores if they
needed to modify the wheel dependencies. This is very common when
breaking dependency cycles in `pytorch` or `apache-airflow` packages.
With this feature we can support patching external PyPI dependencies via
pip.override tag class to fix package dependencies and/or a broken
`RECORD` metadata file.

Overall design:
* Split the `whl_installer` CLI into two parts - downloading and
extracting.
  Merged in bazel-contrib#1487.
* Add a starlark function which extracts the downloaded wheel applies
patches
  and repackages a wheel (so that the extraction part works as before).
* Add a `override` tag_class to the `pip` extension and allow users to
pass patches
  to be applied to specific wheel files.
* Only the root module is allowed to apply patches. This is to avoid far
away modules
modifying the code of other modules and conflicts between modules and
their patches.

Patches have to be in `unified-diff` format.

Related bazel-contrib#1076, bazel-contrib#1166, bazel-contrib#1120
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

go_binary output paths contain a spurious os_arch component

4 participants