Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Have deps_dirs follow sym links #1046

Closed
ankhers opened this issue Jun 27, 2021 · 1 comment · Fixed by #1394
Closed

Have deps_dirs follow sym links #1046

ankhers opened this issue Jun 27, 2021 · 1 comment · Fixed by #1394

Comments

@ankhers
Copy link

ankhers commented Jun 27, 2021

Is your feature request related to a problem? Please describe.
I have a rebar3 application that is currently being developed locally. Because none of my applications are currently on hex.pm, or anywhere else, I am using rebar3s checkout dependencies at the moment. Unfortunately if I use - "_checkouts/*" in my deps_dirs configuration, the sym links do not appear to be follow as I am not getting any autocomplete for those applications.

Describe the solution you'd like
I would like symlinks to be followed so that I can make use of those applications

Describe alternatives you've considered
N/A

Additional context
N/A
@robertoaloi
Copy link
Member

Thanks for reporting @ankhers . I think this behaviour was introduced by #346. We need to find a way to handle both situations.

@robertoaloi robertoaloi mentioned this issue Jul 15, 2021
Closed
@eproxus eproxus mentioned this issue Mar 25, 2022
Open
the-mikedavis added a commit to the-mikedavis/erlang_ls that referenced this issue Oct 24, 2022
@the-mikedavis
[erlang-ls#1046,erlang-ls#1064] Follow symlinks in `els_utils:resolve…
085100f 
…_paths/2`

erlang-ls#346 discarded any paths containing symlinks since
they broke assumptions about there being a single URI for each module
in calls to `els_utils:find_module/1`.

erlang-ls#648 added prioritization for cases when there are
multiple URIs in `els_utils:find_module/1`, so discarding paths with
symlinks is now no longer necessary.

Following symlinks is necessary when using rebar3 checkout dependencies
(erlang-ls#1046) or when using Bazel
(erlang-ls#1064) since Bazel places dependencies and compiled
files under its cache directory and symlinks the relevant directory in
the cache to the workspace directory.

This change removes the behavior of `els_utils:resolve_paths/2` that
discards paths containing symlinks.
@the-mikedavis the-mikedavis mentioned this issue Oct 24, 2022
Merged
robertoaloi pushed a commit that referenced this issue Nov 8, 2022
@the-mikedavis
[#1046,#1064] Follow symlinks in els_utils:resolve_paths/2 (#1394)
8e4dcf8 
#346 discarded any paths containing symlinks since
they broke assumptions about there being a single URI for each module
in calls to `els_utils:find_module/1`.

#648 added prioritization for cases when there are
multiple URIs in `els_utils:find_module/1`, so discarding paths with
symlinks is now no longer necessary.

Following symlinks is necessary when using rebar3 checkout dependencies
(#1046) or when using Bazel
(#1064) since Bazel places dependencies and compiled
files under its cache directory and symlinks the relevant directory in
the cache to the workspace directory.

This change removes the behavior of `els_utils:resolve_paths/2` that
discards paths containing symlinks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

[#1046,#1064] Follow symlinks in els_utils:resolve_paths/2 the-mikedavis/erlang_ls
2 participants
@robertoaloi @ankhers