[Kedro Starters] I’m wondering, whether custom Ked...
# questions
m
[Kedro Starters] I’m wondering, whether custom Kedro starters (especially from plugins) should have the same behaviour as official ones w.r.t the tags. Kedro starters work with
kedro new --starter=spaceflights
, but when we’ve developed our own starter for Kedro Snowflake, it requires to additionally specify
--checkout=
flag, because of the default mechanism in Kedro:
Copy code
Error: Kedro project template not found at git+<https://github.com/getindata/kedro-snowflake>. Specified tag 0.18.8. The following tags are available: 0.0.1, 0.1.0, 0.1.1.
Is there a way (or if not, I think there should be) for the plugin to specify the default tag to use? The versioning of Kedro should not affect the versioning of custom starters/plugins 🤔
👀 2
👍 1
👍🏼 1
a
This has been discussed a few times before (most recently here onwards). Both I and @Yolan Honoré-Rougé agree with you here: non-official starters should not try to do
--checkout={kedro_version}
but instead not specify any
checkout
unless the user explicitly does so, so that it just checks out the default branch. Are you using the
kedro.starters
entrypoint? If so then you’ll note that it’s not currently possible to specify
checkout
as part of the
KedroStarterSpec
. So you would need to do
kedro new --starter=snowflake --checkout=main
explicitly to get the default branch. As discussed in the GH issue I linked to above, it probably doesn’t make sense to add
checkout
to the
KedroStarterSpec
unless we also change the behaviour so that non-official starters don’t do
--checkout={kedro_version}
. Overall this would be a breaking change but I think we should do it. It’s been discussed enough times and no one has brought up a strong objection to it. It’s just we didn’t get around to doing anything about it yet.
👍 2
👍🏼 1
m
Should I create a follow up issue on GH to introduce this behaviour?
a
@marrrcin yes, go for it! 👍