-
Notifications
You must be signed in to change notification settings - Fork 34
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
Migrate to 0.16.5 #62
Comments
Does anyone wants to take this one? @kaemo @akruszewski @takikadiri? Only the first point though since the second point has bee splitted between #66 and #72 . |
@Galileo-Galilei I could work on this one next week. |
Yes, sure. Do you plan to finish #56 first? I updated the milestones to give visibility to what we prioritize (accordingly to what discussed), but feel free to move it to next release if you're not good to go yet. |
@Galileo-Galilei I've got #56 mostly done so I'll finish it first. |
…Galilei#30 Galileo-Galilei#31 Galileo-Galilei#72 Galileo-Galilei#29 Galileo-Galilei#62 - context access - kedro 16.5 - hook auto registration
Almost all kedro_mlflow features and their tests are now working/passing on kedro 0.16.5, except |
The 0.16.5 release is just out and comes with good and bad news:
The new way to register the config_loader, the pipeline and the catalog make them accessible in a global _hook_manager variable instantiated by get_hook_manager(). This enable us to change get_mlflow_config() which currently:depends heavily on the template, and can only be called when the current working directory is the root of the kedro project. Indeed, when we call this function inside a hook we have no way to access the project path except by reading the.kedro.yml
, but this requires knowing in advance where it is. Thanks to this change, we will be able to access the ConfigLoader instantiated in the ProjectContext inside the hook. This is directly related to this issue: [KED-2143] Adding a ConfigLoader instance into hook specs params kedro-org/kedro#506, and it will enable to fix get_mlflow_config use the working directory instead of given path when called within load_context #30 which is particularly annoying but could not be fixed before this change.break supercharging of config loader by a user (which is quite common for people using TemplatedConfigLoader who are not able to use their customisation within the "mlflow.yml" file).kedro mlflow init
command according to this new template. Should it write in therun.py
ProjectContext
class or in thekedro.yml
hooks
key?The text was updated successfully, but these errors were encountered: