No way to determine runfiles tree including the workspace name

[damienmg]

See #1116 for context. we should expose that information as an env variable

[kchodorow]

I don't think we should, that will encourage bad rule creation.

The plan is to have the runfiles tree like:

x.runfiles/
    main-repo/
        some-file
    another-repo/
        another-file

So if you're running in main-repo, you can get another-file via ../another-repo/another-file. If you're working on another-repo, you can still get another-file via ../another-repo/another-file.

[damienmg]

Indeed, but right now the path is undecided, do you have a better idea for the transition?

[kchodorow]

Well, I'm hoping to get a cl out this week, so no.

[damienmg]

Ok let's close this one and just accept the breakage at HEAD for now

[shahms]

How will that work with runfiles found via //external?

[shahms]

And, more generally, for data dependencies specified via $(location <target>)? At least based on #1116 and your discussion above, we'll have to hard code the repository when referencing those runfiles dependencies?

[kchodorow]

How will that work with runfiles found via //external?

Do you mean targets that you've used bind() with? Those will still be available under external/targetname.

And, more generally, for data dependencies specified via $(location )?

This is a bit awkward at the moment. $(location ) will be different than runfiles, and should return the execution-root-relative path, which will still be exec-root/external/repo/path/to/target. However, we're planning to make this match runfiles soon (so it will also be ../repo/path/to/target). Unfortunately, changing this is blocked on an internal change that I'm hoping to get rolled out soon.

[RonnieAtOracle]

we'll have to hard code the repository when referencing those runfiles dependencies

That's what we are doing now and it's not ideal.

[kchodorow]

Unfortunately, there isn't really a way to avoid that if you want your repo to have usable as runfiles by another repository.

[shahms]

That's a pretty huge portability problem for us. We can't easily adjust all of the TEST_SRCDIR relative paths when importing into google3. Based on the discussion in #1116 it seems like PWD should be $TEST_SRCDIR/{workspace_name} (which would be fine) but is, instead, just TEST_SRCDIR.

[shahms]

At least, if we want to actually specify a workspace name.

[shahms]

Sigh; actually while it is a hurdle, we're already doing some shenanigans to work around it. Having to include the workspace name in those shouldn't be too additionally onerous.

[kchodorow]

I think the TEST_SRCDIR thing is actually a bug, it should be TEST_SRCDIR/{workspace_name}.

[kchodorow]

Actually, no, just checked it out and it and TEST_SRCDIR does not include the workspace name internally, so bazel shouldn't either. Sorry :-/

[shahms]

Assuming "google3" is the internal workspace name (which it appears to be), PWD is documented as being "TEST_SRCDIR/google3". And my experiment shows that the documentation is correct.

[shahms]

Actually, sorry for the confusion, there appears to be something else going on as a quick test in #1126 demonstrates that this is consistent with internal blaze and I'm not sure how our PWD is getting changed.