Refactor meta.yaml lint logic

[ytausch]

Checklist

• [x] Added a news entry

This builds upon #1900 by refactoring the meta.yaml lints out of the ~700 lines lintify_meta_yaml function, modularizing the lint logic. While doing that, I added early returns, simplified code and fixed smaller issues.

I think a modularized logic like this is a lot more maintainable, but the path forward should definitely be using more Pydantic models for interacting with complex JSON / YAML files.

1900 needs to be merged first.

[ytausch]

Cc @0xbe7a

[beckermr]

Any public method should be assumed to be used. As I said before on another pr, unless we plan to release v4, there can be no api changes.

[beckermr]

Also, we should not be introducing any deprecation processes unless core is in agreement on how they work.

[xhochy]

Also, we should not be introducing any deprecation processes unless core is in agreement on how they work.

Where should we discuss this? Probably a new issue in this repo?

Still, I'm wondering who the users could be that depend on these functions? I would expect that they are only used inside of conda-forge and thus I would expect that the only thing to do would be to ensure that these functions are no longer used anywhere in our codebase.

[beckermr]

Yes a new issue is fine and then on a core call.

We're going to bust something for somebody even if we don't know about it. We use semver and that has meaning.

[beckermr]

Also while I'm not opposed to making the functions shorter here, the style in which these PRs are being made is making them difficult/impossible for me to review.

• This pr has a net change of ~3000 lines of code. That's way too much for me personally to review. I think a series of smaller prs around at most a net change of 500 lines of code would be much better.
• It apparently mixes api deprecations and refactoring. Each PR needs to be about one thing (eg new api or early returns, or something else, etc). It takes practice to learn how to make PRs like that, but they help them get proper review and discussion.
• The logic for breaking up a big function is clear. I am sure this can be done by only adding APIs.
• If one is proposing an API change, then the reason for it should be clearly stated. Simply changing them to ones that a given developer thinks are better is not IMHO sufficient justification. We should, IMO, have a technical reason why a given API has to be removed as opposed to us simply making a new one for use in some new feature.

[wolfv]

hey @ytausch - I think we merged some similar refactors in #1981 - I hope you didn't mind. Do you want to check if we should still cherry-pick some changes from your branch?

[ytausch]

Thanks for pointing out @wolfv!

I will have a look at this again once #1919 is merged, which was the reason this is blocked altogether