provide linter hints about adding stdlib, removing outdated ways to do it

[h-vetinari]

As discussed in core call today; I wanted to add this into run_conda_forge_specific originally (where the other hint logic from #1772 lives¹, but it's a pain to run that in testing because run_conda_forge_specific requires a GH_TOKEN. If desired, I can still move it there, especially now that the tests have been debugged (and assuming CI here has a valid token). 🤷

Note: I'd also want to wait before merging releasing this until we have updated the stdlib docs in the knowledge base, to avoid people getting confused.

Footnotes

1. which we cannot reuse because it currently only works for plain package names, no patterns, versions etc. ↩

[beckermr]

I didn't follow why a token was needed or w/e with the tests. However, LGTM!

[h-vetinari]

I didn't follow why a token was needed or w/e with the tests.

Calling run_conda_forge_specific immediately runs into

conda-smithy/conda_smithy/lint_recipe.py

Lines 851 to 852 in 4006d83

	def run_conda_forge_specific(meta, recipe_dir, lints, hints):
	gh = github.Github(os.environ["GH_TOKEN"])

(and faking that token is no use because it is soon after used to fetch info from GH).

Hence testing run_conda_forge_specific needs a valid token, whereas "just" calling lintify_forge_yaml does not run into this constraint.

[beckermr]

We could guard those lines and calls to enable things to be run easily without tokens.

[h-vetinari]

We could guard those lines and calls to enable things to be run easily without tokens.

Sure. Not sure though if it's worth the effort? For now it seems to work OK as is and doesn't seem tooooo ugly? (then again, perhaps I also haven't understood where exactly the split between run_conda_forge_specific and lintify_forge_yaml should be). How about a follow-up issue?

[h-vetinari]

OK, now that we have some basic documentation for stdlib up, let's put this one in. :)

[ytausch]

@h-vetinari @beckermr I suggest not introducing any new code that uses io.open. In Python 3, the preferred way should be just open, which is equivalent to io.open.

[jakirkham]

Maybe someone can add an appropriate ruff configuration to the linters here

[h-vetinari]

I suggest not introducing any new code that uses io.open. In Python 3, the preferred way should be just open, which is equivalent to io.open.

Yeah, completely fine by me, I just happened to overlook this while C&P-ing from pre-existing smithy code.

[ytausch]

Maybe someone can add an appropriate ruff configuration to the linters here

Done. See #1919