References to other recipes are interpreted as relative to pwd

[sievertst]

When you reference another recipe as an ingredient, the link appears to be interpreted by the cli as relative to the current pwd rather than the recipe’s location. For instance, say you have two recipes Chicken stock.cook and Chicken soup.cook in the same directory, where the latter contains the following:

Pour @./Chicken stock{1%l} into a pot.

cook doctor validate considers this valid if and only ifyou invoke it from the same directory. If you invoke it from a parent directory, it reports an invalid reference.

I would expect the reference to be interpreted as relative to the referencing recipe’s location because the way it is, I have to validate each directory with such recipes separately.

Thanks for your awesome work! This seems like a very interesting project!

[sievertst]

I just found out that it does work if you leave out the leading ./. Not sure if the behaviour with ./ should still count as an issue then – if you don’t think it does please feel free to close. But maybe the behaviour is at least worth pointing out in the documentation because currently all examples I could find did use the leading ./.

EDIT: Sorry, all-clear canceled. I thought the problem was solved because the version without ./ was validated fine, but looking at the output of cook recipe, the ingredient in question is simply listed as a normal ingredient rather than as a reference.

By the way, a reference whose path has leading ../ in another recipe works flawlessly (at least cook doctor validate accepts it regardless from where I invoke it and it is also parsed correctly as a reference).

[dubadub]

It's a bit of a grey area here. You're right, in CLI I implemented lookup only relative to a folder with recipes (base path). This approach is simpler, but maybe not intuitive.

The original proposal doesn't specify rules how recipe look up should be done (oops!). And it didn't come up during discussion. The question is what's the user expectation here. I think can be both. Need to discuss.

Also, I think ../ isn't supported by the parser (well, it will recognise reference but .. bit will be lost.

[sievertst]

The original proposal doesn't specify rules how recipe look up should be done (oops!). And it didn't come up during discussion. The question is what's the user expectation here. I think can be both. Need to discuss.

Fair. I think there is a strong argument to be made for relative paths (i.e. to the recipe): If such paths are not allowed, usability is becomes much more limited. The user is essentially limited to using a single directory from which the commands can be reliably invoked. This is natural if you put all your recipes next to each other in the same directory, but not if you have subdirectories – and to me it feels quite natural to group recipes belonging to a similar category into a subdirectory.

Such a use case is not entirely unsupported right now, but to make it work you have to decide on a directory from where you will always invoke the commands (presumably the root directory) and then write all your references relative to that directory rather than the one in which you’re working when you write the recipe. That feels rather unintuitive to me.

If we had relative paths, this friction would be removed. In addition,you could invoke the commands from a subdirectory to limit them to recipes in that directory. This is possible right now by using the -b flag, but simply moving to the subdirectory also feels like a very intuitive thing to do.

As for ../, it is recognized as a reference, but it appears to behave exactly like ./ – i.e. everything up to and including the first slash is ignored and the rest is interpreted as relative to the pwd while invoking the command (including searching up the tree if there are more ../ after the first slash.

[sievertst]

I just had a thought which serves as a counterargument: If lookup is relative to the recipe, that obviously fixes the folder structure into the recipes. Suppose I want to move or rename a recipe. I now have to find and update all updates that reference it. Worse, suppose I want to rename/move a directory. Then I have to track down all references to any children (recursively) from the outside. There is an argument to be made that such action at a distance is also surprising and annoying.

That said, the current state has the same issue and additionally the one which I found surprising above, where recipes can be flagged invalid if the command is not invoked from the exact right position in the folder structure.

One solution I can think of: Say we have something marking the root directory of our collection (say, a .cookconfig file). Then if cook is called from anywhere in the tree, it would crawl up directories until it finds that marker and invoke the command proper from there. Now we could define in the spec that references have to be relative to the root. That may be a bit unintuitive to the author of the recipe, because they have to think from the perspective of a different directory then what‘s probably their current one. It also wouldn‘t fix the issue where moving one recipe breaks others. But at least parsing would be consistent, regardless where in the tree the command was invoked.

Alternatively, there could be a mechanism which imports recipes independent of their file name and path from the root. That could be a crawler which recursively traverses all subdirectories of the root and includes everything (not sure how slow that would be – but maybe acceptable if we hold off on parsing more than the metadata and/or there is some way to cache results for later commands). Then recipes could reference each other by title rather than file path.

Advantages:

• moving a file no longer requires us to change other recipes
• maybe it‘s more intuitive to refer to the name in a recipe than a path

Disadvantages:

• almost certainly slower than direct path lookup – how big do collections have to get for it to become noticeably so?
• now we have to change other recipes if the title changes instead
  • but maybe that is less likely?
  • at the very least parent directories can be changed safely
• now one has to be careful not to give two recipes the same title. With path lookup the file system prevents collisions for us
• maybe reference syntax needs to be changed because ./ definitely screams path
  • but do references really need a separate syntax from regular ingredients at all? Could cook commands simply treat any ingredient whose name matches an imported title as a reference?

I‘m not convinced the advantages outweigh the disadvantages here … Thoughts?