-
Notifications
You must be signed in to change notification settings - Fork 110
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
Add directive to support running included scripts in their own working dir #184
Comments
This would be helpful for my projects as well. |
chen-factual
added a commit
that referenced
this issue
Aug 3, 2015
…contained steps from the directory of the included Drakefile. #184
chen-factual
added a commit
that referenced
this issue
Aug 5, 2015
chen-factual
added a commit
that referenced
this issue
Aug 5, 2015
chen-factual
added a commit
that referenced
this issue
Aug 7, 2015
chen-factual
added a commit
that referenced
this issue
Sep 15, 2015
chen-factual
added a commit
that referenced
this issue
Oct 5, 2015
…e not compatible with %context. #184
chen-factual
added a commit
that referenced
this issue
Oct 21, 2015
chen-factual
added a commit
that referenced
this issue
Oct 21, 2015
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For example, if I have a project I've divided into chunks:
And the top level
overall.d
%include
sfoo.d
andbar.d
. Then insidefoo.d
, to runfoo.sh
in a step, I must saysub-workflows/foo/foo.sh
. In other words, it's impossible to implement the submodulefoo
as its own modular piece; it must know about the top level project and that it lives in the subdirectorysub-workflows/foo
.In this case, it's not so bad, because at least they're all in the same project. Let's look at the multiple project case. If I had a
proj_a.d
in project A try to include aproj_b.d
in project B,proj_b.d
cannot reference any scripts in project B unless it has knowledge of it's relative path to project A, sinceproj_a.d
'd directory is the working directory.The implication here is that Drake workflows can never be built to be truly modular pieces that can be composed together by other Drake workflows.
I propose a new % directive, similar to %include, except included workflows maintain their working directories. I've discussed with @amalloy and convinced him of the need for this, and he is tentatively not against it, provided it is possible to implement given JVM constraints. Brief research shows the JNR POSIX project might get us what we need. There is a call to libc's chdir that looks like it might actually change the working directory. It looks like it's at least worth a try.
The text was updated successfully, but these errors were encountered: