-
-
Notifications
You must be signed in to change notification settings - Fork 503
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
Document new multi-pkg migration functionality #6027
Comments
You mean add new functionality to the already fragile variant algebra in conda-smithy? |
I mean: shift (or copy) the same logic as currently done to populate the bot migration yamls to be applied after reading a given migrator yaml, before any variant algebra is applied. That way it would be possible to manually open migration PRs for the affected coupled libraries with setting only the top-level key, rather than restrict the benefit of broadcasting to only bot-generated PRs. As a side benefit, it would be possible to update the broadcast relationship in the same PR as a new migrator, rather than being forced to do everything manually or wait for the bot. |
Sounds too complicated. Simpler the better. |
It's exactly as complicated as the current setup, just that the logic gets applied in a different place. |
From a maintainer perspective, it is. Currently you look at a migration file and you know what is being changed. With your suggestion, there's another layer of indirection that a maintainer has to be aware of and check. |
I do like the fact that the migrator files are "fully detailed" and don't require any additional indirection. Personally, I even find the global pinning file like "alot" of indirection but I'm glad that the version is written in the commit message. |
Neither #6013 nor regro/cf-scripts#2706 document anything. I had asked for clarification in #6013 a couple days ago. CC @isuruf
AFAICT from scattered comments (and tests in regro/cf-scripts#2706), the intention is for the migrator bot to populate the migration yaml with all respective keys?
If so, why not do the broadcast from packages_to_migrate_together.yaml when applying the migrator, rather than when creating it? That way it would suffice to simply set one version in the migrator.
The text was updated successfully, but these errors were encountered: