-
-
Notifications
You must be signed in to change notification settings - Fork 27
Add CFEP for package renames #64
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
base: main
Are you sure you want to change the base?
Conversation
beckermr
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a concept called the feedstock epoch to help us track how feedstocks are reused and to help us easily find all of the artifacts from the previous project(s) built in the feedstock.
What do you think?
|
Also thank you for writing this! |
|
comments @jaimergp ? |
|
@conda-forge/core comments welcome! |
isuruf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't like the extra complication with the feedstock epoch. It's just too much to wrap our heads around.
|
That's fair. My concern is that overtime we'll loose track of the renames and which versions of the feedstock each artifact came from. I'm sure all of this can be automated. Would the automation help assuage your concern or is it deeper than the practical bits of actually making all of the labels etc.? |
h-vetinari
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for writing this up! I think there's still some things to be fixed/improved.
cfep-XX.md
Outdated
| When an existing package wants to be renamed to a currently unclaimed name, the process is uncontroversial and straight-forward. Two approaches are possible: | ||
|
|
||
| - The new name needs to be registered to the originating feedstock in `feedstock-outputs` (or equivalent). Once approved, a PR in the feedstock adding the new output may proceed normally. The old name MUST be kept as an alias output for backwards compatibility. In this case, the feedstock retains the name of the original name. | ||
| - The original feedstock is archived and the package is re-submitted to `staged-recipes` (or equivalent) under the new name. The old package name MUST be added as an alias output for backwards compatibility, and MUST be registered as a valid output of the new feedstock in `feedstock-outputs`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be tempted to descope this from the first iteration of the CFEP. IMO feedstock rename handling might need its own CFEP, but I don't want to block progress here - given we have a concrete case that would need the policy - based on a concern that's not relevant to that particular case.
But basically my position is that feedstock renames should ~never happen, and if they do, they:
- need to meet a very high bar in terms of benefit1
- need to go through staged-recipes
- must force-push the old history (or merge it in with
--allow-unrelated-histories) - provide an explanation (maybe in a pinned issue or a special README section) about the feedstock history, and where to find the relevant issues/PRs from before
Footnotes
-
basically, I want to leave the door open for us to do foundational infra work à la https://github.com/conda-forge/ctng-compilers-feedstock/issues/188, but not make this a common occurrence in conda-forge. ↩
|
OK @isuruf @h-vetinari @jaimergp This is ready for another look! |
h-vetinari
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot, this is getting better and better IMO! A few remaining nits & open points
isuruf
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are our thoughts on using epochs in the version? conda metadata spec supports epochs.
I've made a suggestion about this in one of the review threads. Happy to hear other people's thoughts on this. |
They are not very user friendly, but if folks want to use them for their packages, then I'd let them go ahead personally. I personally don't think we need core to review their usage. |
Co-authored-by: h-vetinari <[email protected]>
I meant we could require an |
|
Ohhhh yeah I'm not in favor of that if we don't need it. |
|
Here's another fun puzzler about a package name (
So now we're in a situation where I don't think it's worth trying to come up with rules that cover such convoluted cases, but IMO, we should mark that single |
|
Yeah indeed that makes sense! This why practically every other statement in the CFEP comes down to "the core team can take actions to set things right in weird edge cases." ;p |
|
Hi @conda-forge/core, do you perhaps have any update on this? Thank you in advance :) |
Comes from conda-forge/admin-requests#1711
markdown preview