Provide better error message when running project command like `kedro run` not from the root directory
Signed-off-by: Nok Chan [email protected]
Description
Spinning off from #1713
The goal is to provide a more helpful message instead of run command is not found when user is running Kedro's CLI not from the project directory.
Notes
- This PR already added a better error message
Points to discuss for Backlog grooming
- Should we take one more step to enable user run
kedro xxxnot from the top-directory instead of just showing the help message? (
Antony raised some good questions in #1713
- not at all sure about using black for find_project_root. Note we have something similar _find_kedro_project in the ipython extension; if that seems suitable to reuse, let's move it to some common utils file and use it here
- more importantly, if we are inside a kedro project, just not at the top level, is there actually any reason these project commands shouldn't work? 🤔 Instead of an error message telling the user to cd can we actually just somehow make kedro work inside a project subfolder (like kedro ipython does)? But without cding to the kedro project top-level
- if we're totally outside a kedro project, a helpful error message is great but:
- is there some better way to check if the command is a project one without overriding get_command, e.g. check if it's in self.project_groups?
- I don't think this formatting is "on brand" yet since we haven't moved the rest of the CLI to rich yet. Let's just do it as click.secho for now. Doing rich styling for CLI messages is a separate issue for another time (e.g. we might move to https://github.com/ewels/rich-click)
Example
The current implementation will try to find the project directory and shows a more helpful error message when user is running kedro run not from the top directory.

Checklist
- [ ] Read the contributing guidelines
- [ ] Opened this PR as a 'Draft Pull Request' if it is work-in-progress
- [ ] Updated the documentation to reflect the code changes
- [ ] Added a description of this change in the
RELEASE.mdfile - [ ] Added tests to cover my changes
More evidence that this would be handy: https://github.com/kedro-org/kedro/issues/1091.
My current feeling is that we should just allow kedro project commands to be run anywhere within the project directory (not just root), like we can already do with kedro ipython. The error message here is still useful if you're not inside the project directory at all, but in the case that you are somewhere inside the project it would be nice if things just worked rather than giving an error.
My current feeling is that we should just allow kedro project commands to be run anywhere within the project directory (not just root), like we can already do with kedro ipython. The error message here is still useful if you're not inside the project directory at all, but in the case that you are somewhere inside the project it would be nice if things just worked rather than giving an error.
When you say "we can already do with kedro ipython" do you mean we can run a KedroSession not from the root directory? Since I don't think any Kedro's project commands are available.
https://github.com/kedro-org/kedro/blob/e882862f0eeaa16656ad9d01abbae083fc47bd4c/kedro/extras/extensions/ipython.py#L51-L67
@noklam I mean you can do kedro ipython from any directory that's inside a project, e.g. from inside <project_root>/notebooks folder. All we do is iterate up through parent directories and supply KedroSession with the right path according to that (see _find_kedro_project). Why shouldn't all kedro project commands work that way? i.e. why shouldn't I be able to do kedro run from inside a subdirectory of <project_root>. I don't think it would be hard to enable and I don't see why we don't already let people do that.
To do: check how other tools (e.g. git) handle operations inside a project that are not in the project root. If they allow this then we should too for all project commands (e.g. kedro run).
Closed for now, for future implementation for #1820 we can take this PR as reference.