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

Support packaging raw symlinks from declare_symlink #929

Open
rickeylev opened this issue Jan 28, 2025 · 1 comment
Open

Support packaging raw symlinks from declare_symlink #929

rickeylev opened this issue Jan 28, 2025 · 1 comment

Comments

@rickeylev
Copy link

Over in rules_python, declare_symlink() is used to create symlinks for efficiency and correctness reasons. Such artifacts are "raw" symlinks, that is, Bazel will keep them exactly as-is and not try to transform them, as happens when using declare_file().

Unfortunately, pkg_tar gives an error when it sees these artifacts. What happens is it thinks the file is a regular file, so tries to read it. Since its a relative symlink, it either is dangling (in the context of pkg_tar), or will read the actual file (instead of creating a symlink), neither of which is desirable behavior.

Thankfully, starting in Bazel 8, File.is_symlink can be used to detect these artifacts. This allows the manifest that pkg_tar generates, and the build_tar program that uses it, to handle them correctly.

The two basic changes are:

  1. When File.is_symlink is true, write a manifest entry with entry_type=raw_symlink (pkg_files.bzl)
  2. Modify build_tar.py to handle entry_type=raw_symlink: read os.readlink() from the src file. Then store it as a symlink. This preserves the original symlink.

I prototyped this a bit and it seems to work. I'd reference my branch, but its in a very hacky and broken state right now. The above gets the gist though

@rickeylev
Copy link
Author

I sent out #930 to demonstrate the gist of fixes necessary for pkg_tar.

Something to note is that File.is_symlink is a Bazel 8+ API. For earlier versions of Bazel, I'm not aware of a way to detect these. For earlier Bazel versions, a workaround I thought of is to have rules_pkg check for OutputGroupInfo.files_that_are_symlinks. A separate provider could be used, too. The reason I suggest a more structural-based approach is to avoid the issue of language rules having to export multiple packaging-implementation-specific providers or vice versa.

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

No branches or pull requests

1 participant