Don't follow symlinks on project root

[memeplex]

Expected behavior

If my project root is a symlink I don't want it to be expanded/followed by projectile. For example, I have a project in dropbox ~/dbox/project where ~/dbox -> ~/home/apps/Dropbox is a symlink. There is a .projectile marker there. I've even manually edited the project roots file and added ~/dbox/project. Now when I open a file file in the project using C-c p p the buffer file name is ~/apps/Dropbox/project/file instead of ~/dbox/project/file. This plays bad with my config which I don't want to depend on the explicit location of the Dropbox folder, I want to keep this fact isolated behind the symlink.

Moreover, the project roots file is updated with a redundant ~/apps/Dropbox/project, even if ~/dbox/project was already there.

Actual behavior

Described above.

Steps to reproduce the problem

Described above.

Environment & Version information

Projectile version information

Projectile 20190126.1117

Emacs version

GNU Emacs 26.1.92 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5) of 2019-03-09

Operating system

Arch Linux

[memeplex]

This is caused by calling file-truename in projectile-project-root. Although I understand why this is necessary, I still think the directory must be returned in the exact form of one of the configured roots (maybe selecting it with file-in-directory-p), the internally used form shouldn't be exposed at the level of buffer-file-name or in the list of projects shown by C-c p p. From my perspective as a user, I'm interested in ~/dbox/project, I don't even known what ~/apps/Dropbox/project is and, say, I would like to match buffer-file-name against ~/dbox during some hook execution.

[memeplex]

For now I'm workarounding it like this:

(defun my-dbox-path-advice (dir)
  (replace-regexp-in-string "apps/Dropbox" "dbox" dir))
(advice-add #'file-truename :filter-return #'my-dbox-path-advice)

Moreover, this is also required for treemacs to work, although I'm not sure whether it's because of the way it queries projectile or because it has the same "truename" behavior itself.

[jimmywongroo]

There's a PR (#566 ) to fix this, seems like this is a recurring problem.

[ilysym]

This is caused by calling file-truename in projectile-project-root. Although I understand why this is necessary

Is this really necessary? file-truename is applied to default-directory which is always an absolute path. What needed there is the absolute path, not dereferenced "true" path, right? I've simply replaced (file-truename dir) with dir and it seem to work fine.

[memeplex]

What needed there is the absolute path

It depends on what you prefer: open the same underlying file one or many times. In the first case you need an absolute and unique path (except that emacs defaulted to the already opened file no matter what the alias were, which I don't know and can't test right now).

[madscientist]

The problem with using the truename (resolved symlinks) is that many/most interfaces don't do that. if projectile forces the project root path to be the truename then it doesn't work with these other tools.

For example, suppose I have a workspace with truename /real/root/workspace but I have a symlink /work -> /real/root and I always cd to /work/workspace. Then when I run cmake, for example, it will generate compile_commands.json files containing the /work/workspace paths, not the truepath /real/root/workspace. All other tools, such as ccls etc., will be using the symlink path. All these tools stop working properly because they don't agree with projectile about the project root.

I'm not sure how to resolve this issue perfectly for all cases. However, I will say this: I think it's most common for people to always use the same way to find their project root. If there's a symlink then they will either always use the symlink or, i guess, never use the symlink. I think it's highly unusual for someone to use both the symlink and non-symlink methods of locating the same root within the same environment.

The typical reason for using a symlink in the first place is that you have a particular way that you always want to access your workspaces, but due to partition size issues, or remote mounting issues, or whatever, you cannot use a physical directory in the location where you want it on some particular systems. So you use a symlink to make all the systems look the same. In these situations you want to always use the symlink path.

I think that this model (always using the path the user provided even if it's not the true path) is the one that we should optimize the system to support, and other less common usages, if needed at all, should require some special option to enable.

[memeplex]

@madscientist I agree with everything you have said. My first feature request was to use absolute path indeed, not true name at all, but then I accepted some people may prefer to avoid duplicated views (still I don't know if emacs already handles this by focusing a buffer already showing the same file under a different alias) or there might be implementation reasons (say caching) to avoid aliases. So my compromise solution was: ok then, use true name internally but, after resolving the root, map it to one of the user configured paths so both parts are happy. Doesn't seem difficult to achive, just iterating the list of roots and comparing them by truename with the resolved root for some file, then returning the root as configured and not as resolved.

[madscientist]

Yep, I was just trying to bolster your case 😄 I'm trying to put together an Emacs IDE configuration to publish to my co-workers, and this issue with symlinked root directories is basically the last problem I need to solve before I can do that; it's working pretty well for environments that don't use symlinks but fails utterly when they do: LSP support is non-functional.

[dolmens]

Encountered the same problem, need to use the root's symlinks instead of absolute path.

[xaviergmail]

I have a slightly different use case with a similar undesired outcome.

My project root is a real directory (~/projects/foo)
But within that root are symlinks to that point elsewhere on the filesystem.

• ~/projects/foo/project1 points to /mnt/foo/bar/project1
• ~/projects/foo/project2 points to /mnt/foo/bar/project2

To make matters worse, the directories liked to are also git repositories, which seem to take precedence.

I have made an attempt at describing my use case in this StackOverflow question

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding!

[stale]

This issues been automatically closed due to lack of activity. Feel free to re-open it if you ever come back to it.