Bug: {fileProjectPath} with multiple project folders

[stefanvollmar]

While {fileProjectPath} has worked flawlessly for us so far, we have just come across one specific case where this is incorrect (but which might be easy to fix). To reproduce, configure two "project folders" in Atom where one is a subdirectory of the other, e.g.

>betadir
  |-somefile

>alphadir
  |-betadir
     |-somefile
  |-scripts
     |-somescript
  |-process-palette.json

now open "somefile" and trigger an action with process-palette. While {fileProjectPath} should be "/path/to/alphadir", in this scenario it seems to return "/path/to/alphadir/betadir". If instead of "betadir" (which is a subdirectory of "alphadir") an entirely independent project folder is configured, {fileProjectPath} seems to be correct. This is a serious problem if {fileProjectPath} is used to start a script within the alphadir-tree - where "{fileProjectPath}/scripts/somescript" then does not work reliably (it does work very well indeed, except in this specific setup with multiple project folders).

[morassman]

This is a use case I haven't considered before. Which project the file belongs to is ambiguous in this case, because it actually belongs to both betadir and alphadir.

I use this Atom function to determine what {fileProjectPath} is. I give it the path of the file and it returns the project path.

I looked at the implementation of that function and it seems to return the path of the first project it finds that contains the given file.

Atom is therefore not helping us in this case. Additional checks on my side will be necessary to detect if there is an ambiguity.

If I build in this kind of detection, what would you suggest would be the best way to respond to it? The easiest would be to prevent the command from executing and notify the user with a warning. One can get creative with solutions, such as prompt the user to choose the project that should be used or make an informed decision about which project path to choose based on some logic, etc.

[stefanvollmar]

The use case is unusual - but might make sense (in our case it did not). I had assumed the reason for the problem was as you described. Here is a simple suggestion: if there is ambiguity, return the project that has a "process-palette.json" file at its root level (the "active" one?). If there is more than one candidate, abort with a suitable error message.

[hg42]

I think usually, when only path based, the associated project would be the most inner containing the file, but I can also imagine cases where it should be the most outer project. May be for the later there should be a new variable.

Atom could also remember from what project tree the file was opened. But currentlyy there is no visualization for that, so the user would need to remember from which sub tree each file was opened.

Apart from that I think Atom's implementation is too simplistic.
Two loaded and nested projects seem to be weird, but I also had this case before.
I guess, Atom's implementation should be fixed.