Skip to content

Conversation

@jaimergp
Copy link
Member

@jaimergp jaimergp commented Oct 26, 2025

Copy link
Member

@beckermr beckermr left a 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?

@beckermr
Copy link
Member

Also thank you for writing this!

@beckermr
Copy link
Member

comments @jaimergp ?

@beckermr
Copy link
Member

@conda-forge/core comments welcome!

Copy link
Member

@isuruf isuruf left a 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.

@beckermr
Copy link
Member

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.?

Copy link
Member

@h-vetinari h-vetinari left a 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`.
Copy link
Member

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

  1. 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.

@beckermr
Copy link
Member

beckermr commented Nov 3, 2025

OK @isuruf @h-vetinari @jaimergp This is ready for another look!

Copy link
Member

@h-vetinari h-vetinari left a 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

Copy link
Member

@isuruf isuruf left a 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.

@h-vetinari
Copy link
Member

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.

@beckermr
Copy link
Member

beckermr commented Nov 4, 2025

What are our thoughts on using epochs in the version? conda metadata spec supports epochs.

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.

@isuruf
Copy link
Member

isuruf commented Nov 4, 2025

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.

I meant we could require an epoch bump when a package name is reused.

@beckermr
Copy link
Member

beckermr commented Nov 4, 2025

Ohhhh yeah I'm not in favor of that if we don't need it.

@h-vetinari
Copy link
Member

Here's another fun puzzler about a package name (ouroboros) with a convoluted history (from conda-forge/ouroboros-gis-feedstock#10).

Time What PyPI conda-forge
~2016 Name reserved on PyPI; never any release ouroboros (https://github.com/beeware/ouroboros) -
July 2025 Unrelated project plans to take
over abandoned name; takes
name in conda-forge (PR 1, PR 2)
abandoned ouroboros (https://github.com/corbel-spatial/ouroboros)
Aug. 2025 A third project requests the ouroboros name, gets it ouroboros (not yet open-sourced) ouroboros (https://github.com/corbel-spatial/ouroboros)
Oct. 2025 The geospatial ouroboros asks
for the original PyPI name,
realizes it is too late
ouroboros (not yet open-sourced) ouroboros (https://github.com/corbel-spatial/ouroboros)

So now we're in a situation where ouroboros (https://github.com/corbel-spatial/ouroboros) was reserved in conda-forge in anticipation of inheriting the PyPI name, which didn't happen for unforeseeable reasons. There's a single release of ouroboros on conda-forge right now, which is just a wrapper package around ouroboros-gis.

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 ouroboros release as broken (let users move to ouroboros-gis), and then keep the ouroboros name free so that we can match the PyPI project that's now called ouroboros, once it makes a release.

@beckermr
Copy link
Member

beckermr commented Nov 4, 2025

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

@flferretti
Copy link

Hi @conda-forge/core, do you perhaps have any update on this? Thank you in advance :)

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants