Revamp the linter

[jaimergp]

conda-smithy includes the linter, but in the past (way back!) it was already discussed whether to break it out to a separate package, merge with conda-verify, etc. That didn't happen and we are still here, with an increasing backlog of bugs and feature requests.

My suggestion here is to:

• Create a separate package, e.g. conda-forge-linter or something like that.
• Architect it in a more modular way so we can enumerate all lint and hint rules, with their own unique identifier. This would allow for:
  • Better documentation (e.g. we could have a site like shellcheck's with all the rules, with each lint linked from the CI logs).
  • Optional configurability. While lints are required, hints are not. Users could either silence some of them out if noisy, or conversely, we can introduce optional hints that users can opt into. Maybe this is not a goal, but it would be possible if we ever consider that.
• The new architecture should make it easier to contribute new lints/hints. I envision different "hook levels" where we can add new rules. For example:
  • Raw recipe lint: takes the whole recipe, unparsed.
  • Rendered recipe lint.
  • Per section lints (e.g. only requirements).
  • Non-recipe lints (e.g. conda_build_config.yaml).

... and in general, seek inspiration in other Python linters like pylint or flake8 (the code in this one is particularly easy to follow, and is well structured).

We have made great advances with the recent refactors for recipe.yaml, so I'm confident this is workable! Let me know your thoughts.

[beckermr]

I support this but we need to maintain the current smithy apis both at the command line and in the code unless we plan to bump the smithy major version.

[beckermr]

We've had trouble with api breaks during past refactors.

[msarahan]

At today's conda community meeting, @schuylermartin45 asked about potential unification/collaboration between the linter here and the linter that he helps maintain at Anaconda. Schuyler seemed especially interested in a new codebase using Rust. I encouraged Schuyler (perhaps too strongly) to profile his code and understand whether a Rust conversion would make sense. @wolfv encouraged him towards using the rattler-build python bindings with rust code demonstrating maturin and pyo3 to expose rust to python

For historical reference, I had a project that I never finished that was intended to implement core conda internals in rust, while preserving the rest of conda and conda-build in python. This is an older design that is pretty similar to how rattler-build provides its rust core and CLI, with python bindings.

[beckermr]

Agreed that I doubt linter performance is a bottleneck anywhere or one we care about.

The actual bottlenecks in our current setup in conda forge is that we have to isolate operations in separate vms due to jinja and selectors.

[jaimergp]

Agreed that I doubt linter performance is a bottleneck anywhere or one we care about.

One point brought up during the discussion is that a faster linter (let's say almost instantaneous, <500ms?) would allow for real-time linting in an IDE while editing the file, but I don't think we've demoed this with the current conda-smithy linter either, so not sure how "slow" it feels.

[schuylermartin45]

I understand Python w/ a C YAML parser may not be the most limiting factor. But I have some significant scaling issues on my team's horizon and I'll take performance gains when I can.

In the call I think I also mentioned that I'm willing to make this a V1+ only linter. I assume that would alleviate/eliminate the JINJA/selector issue you are talking about @beckermr

I also mentioned that we started an experimental protected branch in CRM to play with a faster parser for programmatic editing of recipe files: https://github.com/conda/conda-recipe-manager/tree/dev_v1_rust_parser. Ideally, the new linter leverages CRM to automatically fix common linting issues, when possible.

If that pans out, we should coordinate to leverage rattler-build's existing parsing work, as suggested by @wolfv on the call.

[beckermr]

Clearly, I cannot dictate what people do or don't do, nor do I know about your internal scaling issues. I also do not have a strong preference for limiting things to v1 vs v0. If you want to spend time and effort on features like instantaneous linting, or extremely optimized parsing in rust, go for it.

On the other hand, here are a bunch of things that likely need fixing from the point of view of conda-forge and the conda community at large (that would like to use CRM):

• Improve V0 --> V1 conversion support for join and split operations in JINJA conda/conda-recipe-manager#327
• Investigate failing to parse {% set ... %} statements in the middle of a recipe file. conda/conda-recipe-manager#318
• Multi-line strings containing quotes breaks the parser conda/conda-recipe-manager#220
• Parser is not resilient to mixed indentation conda/conda-recipe-manager#221
• cannot parse recipe with jinja {% if branches conda/conda-recipe-manager#258
• fails to parse summary with colon conda/conda-recipe-manager#284
• Add full support for evaluating V0 JINJA ternary variables conda/conda-recipe-manager#285
• Usage of a != version specifier causes a parsing exception conda/conda-recipe-manager#297
• Error converting a recipe with a set python_min variable conda/conda-recipe-manager#307
• V1 recipe should contain ${{ python_min }}.* instead of ${{ python_min }} conda/conda-recipe-manager#308
• Add tests[].python.python_version in V1 recipe conda/conda-recipe-manager#309
• Invalid and empty script test section in V1 recipe conda/conda-recipe-manager#310

You and Anaconda Inc have your own priorities, are not responsible for fixing these, and I am not requesting that you all spend time fixing these. People who need those things should fix them.

I am saying that from my point of view, speeding things up with rust feels like something that is secondary.

[schuylermartin45]

I am well aware there is a long list of backlog items to improve the conversion process. Some of them might be faster to fix manually depending on how large the set of afflicted recipe files is. There's nuance here if we need to talk more offline.

Trust me, I'm not happy I've disappointed the community this way. In an ideal world, crm convert would get more attention. But I don't sign my own paychecks and this library is proving to be very valuable to many people and projects.

On the bright side, I now have a small team and although I can't promise much at the current time, I do hope that some of my team members can assist when they ramp-up.

[beckermr]

My comments are not meant to be critical, so my apologies for that.

CRM is great and you've not disappointed anyone IMHO. The community needs to step up for sure if they want these things fixed, as I said above. (For my part, my own efforts have been focused on conda-build. CB will need ongoing attention for a while yet.)

Any effort you have is always appreciated! I got the impression you were asking the community if we thought the rust work would be useful to the community, so I was attempting to give my opinion on that.