Symbolic link project path not working

[jiunbae]

Description

If the project path exists on the symlink, an error occurs when Kedro CLI is created.

Context

Workspace is a symbolic link, but when I run the kedro project on it, I get a problem that it cannot be executed.

on windows

Steps to Reproduce

1. mklink /J workspace /path/to/source
2. cd workspace
3. kedro new
4. kedro info

Expected Result

Actual Result

Traceback (most recent call last):
  File "C:\Users\-\conda\Scripts\kedro-script.py", line 9, in <module>
    sys.exit(main())
  File "C:\Users\-\conda\lib\site-packages\kedro\framework\cli\cli.py", line 265, in main
    cli_collection = KedroCLI(project_path=Path.cwd())
  File "C:\Users\-\conda\lib\site-packages\kedro\framework\cli\cli.py", line 183, in __init__
    self._metadata = bootstrap_project(project_path)
  File "C:\Users\-\conda\lib\site-packages\kedro\framework\startup.py", line 184, in bootstrap_project
    _add_src_to_path(metadata.source_dir, project_path)
  File "C:\Users\-\conda\lib\site-packages\kedro\framework\startup.py", line 168, in _add_src_to_path
    _validate_source_path(source_dir, project_path)
  File "C:\Users\-\conda\lib\site-packages\kedro\framework\startup.py", line 159, in _validate_source_path
    raise ValueError(
ValueError: Source path 'workspace\test\src' has to be relative to your project root 'workspace-link\test'.

Your Environment

• Windows 11 (21H2, 22000.194)
• Python==3.8.10
• Kedro>=0.17.0 (tested 0.17.0, 0.17.5)

[jiunbae]

In my opinion, can simply add resolve to project_path when KedroCLI is created.

from:
https://github.com/quantumblacklabs/kedro/blob/983f7aef8a84fa6078dc92c57bbccdf6a7508526/kedro/framework/cli/cli.py#L264-L266

to:

    _init_plugins()
    cli_collection = KedroCLI(project_path=Path.cwd().resolve())
    cli_collection()

[datajoely]

KedroCLI(project_path=Path.cwd().resolve())

Interesting - thanks for the follow-up @jiunbae this is an elegant solution, I'm trying to think if there are any unintended consequences introduced by making this change.

[jiunbae]

Tried to create a PR, but I left an issue first because it takes times to prepare the things necessary for environment setting such as test, CI and getting used to the kedro contribution convention.

[jiriklein]

Hi @jiunbae - thank you, this looks like a super elegant solution. I had a look at the Path.resolve implementation here (https://docs.python.org/3/library/pathlib.html#pathlib.Path.resolve) and I think for these purposes we'll go with Path.resolve(strict=True).

However, we would need to see tests for Win, Darwin and Linux as the way all of these platforms resolve paths (and symlinks, for that matter) differs and can throw some unexpected behaviour.

[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 contributions.

[tejaassolanki]

The absence of .resolve() on line is also causing problems when running a project from a UNC path on Windows. Windows does not allow UNC paths to be current working directory and hence they need to be mounted to a drive letter. When running any pipeline with the current working directory as a mounted UNC path, the absence of .resolve() raises the exact same ValueError mentioned above by @jiunbae at the start of this thread.

So far, I have been using the .resolve() method in Windows but I agree with @jiriklein that this needs to be tested for other platforms.

I believe this issue got missed due to inactivity. Hence, the @stalebot closed it.

[astrojuanlu]

Or maybe .absolute()? See gh-2346