"Is a directory" failure #77
Comments
|
tl;dr: no, dirs != files, but output_directories seem like the way to go Ah, that's definitely a no-go. There is, however, this: However its implementation in bazel 0.9 looks like this: And I was very excited to find when I went looking for this, that output_directories now has an implementation in the latest unreleased bazel: For which I will happily mirror an implementation in buildfarm. My guess on documentation for how to add an entry to the |
|
If I use "declary_directory" instead of "declare_file" I receive following problem with symlink to system python (only under linux, under OSX everything works fine) (just local bazel, not farm) Is it expected behavior or another bug in bazel? |
|
I'm going to have to punt to the bazel project for non-buildfarm behaviors around declare_directory |
|
@werkt Yes. My latest comment about local bazel (not a farm). |
|
Looks like a bazel bug to me. My clue: |
@werkt I am very sorry for probably stupid question... Why you do not want to use bazel as external repo in farm? As result you can import libraries from bazel directly to farm and 99% to have correct behavior always |
|
Not stupid, I would say that there are two reasons:
|
|
Thank you! |
|
Any updates? |
|
No movement. Happy to accept a PR if you want this to be accelerated. |
|
You may be interested in bazelbuild/bazel#4668, which I encountered when trying to demonstrate a solution for this. I'll have to proceed without an integration test on this issue until they fix that. |
|
@werkt That's exactly my problem. If you replace "declare_directory" by "declare_file" everything would works fine. |
|
Good, glad we converged on that. That means that you are not getting
digests put together for that, so the output cannot be cached
Hopefully this gets some traction in the next couple of days. Otherwise
I'll have to put up a pull request myself
…On Feb 20, 2018 5:30 PM, "Oleg Tsarev" ***@***.***> wrote:
@werkt <https://github.com/werkt> That's exactly my problem.
That's why my virtualenv rule (and rules_go) use "declare_file" and store
directory instead of file in result.
If you replace "declare_directory" by "declare_file" everything would
works fine.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABTlsIZLKrg-DSOhMp9q-rQ-S2-41yJks5tW0eSgaJpZM4Rcu1r>
.
|
|
@werkt thank you very much for update! |
|
https://github.com/werkt/bazel-buildfarm/tree/output-directories provides an implementation for buildfarm, according to the observed behavior in bazel, and includes some tests. Don't know what to say for in-bazel support for legit output directory specification, but at least we'll be ready... |
|
@werkt good news! I will check in nearest future how buildfarm works now |
|
@werkt I tested https://github.com/werkt/bazel-buildfarm/tree/output-directories and it works. |
|
Thanks @pauldraper, the PR is only currently held up by me - there is substantially strange behavior that needs to be considered when working with output directories, specifically intersections with other output files/dirs, and other inputs. The initial behavior will be to reject these outliers, and I have to clean things up a little more in the change to reject those conditions as invalid initially. |
|
Implemented in #128 and landed |
Hello,
I tried to use buildfarm for build my project.
With notes from #76 it works, except following problem:
rules_go declare some output as file (by "ctx.actions.declare_file"), but really returns the directory.
Same problem with our in-house rule for creating virtualenv.
It is hack, but it works locally.
Without this hash would be too complex to support tools like virtualenv, or golang compilter.
Can we allow behavior like this for buildfarm?
The text was updated successfully, but these errors were encountered: