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

py_binary target inside another Starlark rule's runfiles doesn't get built fully #378

Closed
mzhaom opened this issue Aug 13, 2015 · 11 comments
Closed
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-Python Native rules for Python type: bug untriaged

Comments

@mzhaom
Copy link
Contributor

mzhaom commented Aug 13, 2015

I have a skylark "run_under" rule that essentially does:

bazel run --script_path "name" --run_under "under" "command"
Then run the script

The code is here:
https://github.com/mzhaom/trunk/blob/master/tools/build_rules/run_under.bzl

The behavior I would expect is:

  • Build the "under" target
  • Build the "command" target
  • Produce the wrapper script
  • Then run the wrapper script if it's a test

The issue I got is, if the "under" target is a py_binary, only the
wrapper script for the py_binary is produced, but not the runfiles
symlink tree, as a result, the py_binary can't be run.

I have a reproducible case here:

https://github.com/mzhaom/trunk/blob/master/examples/run_under/BUILD

If I do bazel clean then just run

$ bazel test examples/run_under:hello_test

I got error:

python2: can't open file
'/usr/local/home/_bazel_mzhao/c0fe0a5986a7dee82d17f872b1091a3e/trunk2/bazel-out/local_linux-fastbuild/bin/examples/run_under/env.runfiles/examples/run_under/env.py':
[Errno 2] No such file or directory
@damienmg damienmg added type: bug P2 We'll consider working on this in future. (Assignee optional) labels Aug 18, 2015
@hanwen
Copy link
Contributor

hanwen commented Aug 24, 2015

AFAICT, your rule doesn't add the runfiles for 'under' (eg. 'env') to the runfiles of _run_under_impl.

@hanwen
Copy link
Contributor

hanwen commented Aug 24, 2015

http://bazel.io/docs/skylark/rules.html -> "Rules"

@mzhaom
Copy link
Contributor Author

mzhaom commented Aug 28, 2015

What's the right way to access the 'under''s runfiles? I tried

runfiles=ctx.runfiles(
  files = runfiles,
  transitive_files = ctx.attr.under.transitive_runtime_files,
)

But got the error:

/usr/local/home/mzhao/g/trunk/tools/build_rules/run_under.bzl:42:26: target (rule class of 'py_binary') doesn't have provider 'transitive_runtime_files'.

@mzhaom
Copy link
Contributor Author

mzhaom commented Sep 1, 2015

I made a change my run_under and it works with an older version of bazel:
bazelment/trunk@8f2589b

But it didn't work with the latest bazel which has sandbox enabled:

examples/run_under/hello_test: line 3: /usr/local/home/_bazel_mzhao/7f4ef1d4b60d94ba335123843e5cccc0/trunk/bazel-out/local_linux-fastbuild/bin/examples/run_under/env: No such file or director

It looks like I might miss putting some file into certain dependency so the sandbox doesn't mount it properly. @philwo could you suggest a solution? Thanks!

@philwo
Copy link
Member

philwo commented Sep 2, 2015

I will have a detailed look tomorrow, but here some thoughts:

I don't think the path manipulation, where you process ctx.configuration.bin_dir into "build_directory" and then add the short_name of your "exe" and "under" artifacts gives you the correct path to the files in the runfiles.

You may be able to see the paths where the files are actually to be found if you pass --verbose_failures to "bazel run" when you run your example. The sandbox should then print a lot of debugging output, including a list of mounts. I think you can find your "env" binary in there and maybe with that, you can deduce a better way to get the path in your Skylark script.

I will try to run your example on my workstation tomorrow and see if I can find a solution that works. :)

@damienmg
Copy link
Contributor

@philwo ping? Is that really a bug?

@ulfjack
Copy link
Contributor

ulfjack commented Nov 19, 2015

Runfiles, meh. There's a good chance that there's a bug here, or two.

@dslomov dslomov self-assigned this Dec 8, 2016
@dslomov dslomov added this to the 0.5 milestone Dec 8, 2016
@dslomov
Copy link
Contributor

dslomov commented Dec 8, 2016

Actions API cleanup

@dslomov dslomov modified the milestones: 0.6, 0.5 Dec 20, 2016
@laurentlb laurentlb removed this from the 0.6 milestone Nov 29, 2018
@meisterT meisterT added untriaged and removed P2 We'll consider working on this in future. (Assignee optional) labels May 14, 2020
@brandjon
Copy link
Member

It's unclear if this is still an issue, and if so, whether it's caused by the use of the API or because there's a bug in --run_under.

@brandjon brandjon added P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) team-Build-Language and removed team-Starlark untriaged labels Feb 15, 2021
@brandjon brandjon changed the title py_binary target inside another skylark rule's runfiles doesn't get built fully py_binary target inside another Starlark rule's runfiles doesn't get built fully Feb 15, 2021
@pcjanzen
Copy link
Contributor

related: #11997

@brandjon brandjon added untriaged team-Rules-API API for writing rules/aspects: providers, runfiles, actions, artifacts and removed team-Build-Language labels Nov 4, 2022
@comius comius added team-Rules-Python Native rules for Python and removed team-Rules-API API for writing rules/aspects: providers, runfiles, actions, artifacts labels Feb 15, 2023
@ShreeM01 ShreeM01 added the stale Issues or PRs that are stale (no activity for 30 days) label Feb 16, 2023
@ShreeM01
Copy link
Contributor

Hi there! We're doing a clean up of old issues and will be closing this one. Please reopen if you’d like to discuss anything further. We’ll respond as soon as we have the bandwidth/resources to do so.

@ShreeM01 ShreeM01 closed this as not planned Won't fix, can't repro, duplicate, stale Feb 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) stale Issues or PRs that are stale (no activity for 30 days) team-Rules-Python Native rules for Python type: bug untriaged
Projects
None yet
Development

No branches or pull requests