Look for Sakefile in parent folders as well

[wbiker]

My idea was to be able to have not just one Sakefile in the current folder, instead Sakefiles in parent folders should be find as well. That has the benefit, that tasks can be available or overwritten depending of the current working folder.

For that, I added a method to the pm file plus a test file to test it.
Changed the behavior though. Sake no longer dies if a task already exists. It just ignores the task found in parent folders with the same name. So, always the task is used that is the nearest to the current working dir. That might be not the desired approach for other users.

[coke]

Is there prior art on this for any other build tools?

This seems like it could end up surprising the user.

[wbiker]

Good point.
I was not sure to PR this. But I thought other might be interested in this as well.
So, I am open for discussions

[AlexDaniel]

Is there prior art on this for any other build tools?

Rake does it.

Rakefile:

task :default do
  puts 'default'
end

Trying it out:

alex@librepad:~/raketest/foo$ rake

Output:

(in /home/alex/raketest)
hello

[AlexDaniel]

@wbiker maybe it's a good idea to look how Rake does it. For example, maybe there are some edge cases that need to be covered? Otherwise looks good to me.

[coke]

-0.5 from me.

[wbiker]

I dent to close this PR. Sake is around quite a while and I have no idea what side effects could be shown if it is merged.
Or, should I introduce a command line parameter to enable this code? So, it could be behave like before as default.

[AlexDaniel]

Sake is around quite a while and I have no idea what side effects could be shown if it is merged.

Now is probably the best time to make a change like this.

However, the PR has to be modified I think. One problem, as far as I can see, is that it does not chdir into the directory where the sakefile file is located. That can be a real issue because most Sakefiles will probably expect a bunch of paths to exist, so the functionality shouldn't be “execute any Sakefile in the current directory” but “go back a little if I'm in a subdirectory and run a Sakefile there”.

Also, currently it evals all of the Sakefiles up to / (if I'm not mistaken, just looking at the code), and that's most likely incorrect. If at any time I'd want to EVAL an upper Sakefile, I'd just start the new one with EVALFILE ‘../Sakefile’ or something like that. So this has to be fixed also.

[wbiker]

@AlexDaniel ...it does not chdir into the directory where the sakefile file is located...
My idea was to overwriting tasks in parents folders, not to run them there. So I can have a task 'test', { prove dadada } in /repos/Sakefile and this task is invoked in any subfolder in /repos. Except there is a Sakefile in one of the subfolders with another task 'test' { prove -Iwhatever dadada }, then sake test makes something different.
THat is the idea behind my changes. But I see your point.
What about task attributes. Something like:
task 'test', OVERWRITE, { sdsd }

[wbiker]

Since this issue is more than just looking for sakefiles in the path, I close this.
Nevertheless, I would like work on this because I think it would be useful. Only in this form it is probably useful for me.

[AlexDaniel]

@wbiker Maybe consider making a module that depends on and uses Sake? This way you can have let's say resake command that uses Sake, so you get the best out of Sake yet it will do what you want it to do.

[wbiker]

Thanks. Will stick with my changed code for now. But will think about that