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.

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

Agree upon a unified "configuration" terminology #2434

Closed
astrojuanlu opened this issue Mar 17, 2023 · 7 comments
Closed

Agree upon a unified "configuration" terminology #2434

astrojuanlu opened this issue Mar 17, 2023 · 7 comments

Comments

@astrojuanlu
Copy link
Member

astrojuanlu commented Mar 17, 2023

Maybe we could use 3 different words for 3 different things:

I'm not a native speaker but, even though understanding that "configuration" and "settings" are mostly the same, and that pyproject.toml does indeed contain some "Kedro settings", by at least striving for internal consistency in the terminology we can hopefully minimize confusion.

Originally posted by @astrojuanlu in #2427 (review)

On the other hand, @datajoely proposed a different taxonomy:

image

Originally posted by @datajoely in #2427 (comment)

  • Data config
  • App config
  • Build config

I really like this.


And last but not least, let's not forget config.yml that can be used to programatically call kedro new. I've been advocating internally to move to a CLI flags approach, but I didn't want to pursue the issue further after #1692 is addressed.

@datajoely
Copy link
Contributor

datajoely commented Mar 17, 2023

The most important element is the lifecycle piece:

Data config - Runtime (env, parameters, catalog)
App config - Library component init (Catalog location, ConfigLoader, Pipelines, hooks)
Build config - Project start up (bootstrap, src location etc)

@stichbury stichbury added Component: Documentation 📄 Issue/PR for markdown and API documentation Component: Configuration labels Mar 17, 2023
@astrojuanlu
Copy link
Member Author

Using this "data config", "build config", "app config" terminology now, I'm quite happy with it. In the absence of a better idea, I think we should codify it in the documentation. @datajoely do you have a higher resolution version of the image by any chance?

@datajoely
Copy link
Contributor

@astrojuanlu can yo usee this?
https://miro.com/app/board/o9J_llzgzfk=/?share_link_id=245109814687

@stichbury
Copy link
Contributor

@astrojuanlu and @datajoely

Please can you clarify the documentation tasks here as it's not totally clear what is needed? That is, can you give a set of "rules" for how to use the terminology that you decide upon and where you think the main sections are that need updating? Until I have that kind of checklist to follow, it's a risk to update the text as it could make it more messy rather than less.

I think agreement on terminology is the first issue, and at that point only, does it become a docs ticket. So I'm revising the title of this one and moving it out of docs...you can create a subtask when you have the rubric for docs changes to follow.

@stichbury stichbury changed the title Unify "configuration" terminology Agree upon a unify "configuration" terminology Jul 17, 2023
@stichbury stichbury changed the title Agree upon a unify "configuration" terminology Agree upon a unified "configuration" terminology Jul 17, 2023
@stichbury stichbury removed the Component: Documentation 📄 Issue/PR for markdown and API documentation label Jul 17, 2023
@astrojuanlu
Copy link
Member Author

There's a concrete proposal on #2434 (comment), whenever this becomes a priority let's collect upvotes and/or arguments against it. I personally like it.

@astrojuanlu
Copy link
Member Author

The task here is to agree on the terminology. After we've done that, we can close the issue and open a new one with specific actions for the docs.

@astrojuanlu
Copy link
Member Author

Nobody posed any objections to the terminology so I'm considering this done. For the record:

  • Data config - Runtime (env, parameters, catalog)
  • App config - Library component init (Catalog location, ConfigLoader, Pipelines, hooks)
  • Build config - Project start up (bootstrap, src location etc)

Will be opening new tickets with specific tasks (trying to stay away from catch-all "review docs").

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

3 participants