Remove redundant options documentation and improve formatting

[DanielNoord]

Type of Changes

	Type
✓	📜 Docs

Description

@Pierre-Sassoulas Potentially do this before #6589. I tried to improve the formatting of the options page a little bit. After this we can do one more PR that removes the pylint features page all together I think.

[coveralls]

Pull Request Test Coverage Report for Build 2446647805

• 9 of 11 (81.82%) changed or added relevant lines in 2 files are covered.
• 62 unchanged lines in 5 files lost coverage.
• Overall coverage decreased (-0.01%) to 95.52%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pylint/checkers/base_checker.py	3	4	75.0%
pylint/utils/docs.py	6	7	85.71%

Files with Coverage Reduction	New Missed Lines	%
pylint/checkers/modified_iterating_checker.py	2	97.56%
pylint/config/arguments_manager.py	2	98.22%
pylint/pyreverse/inspector.py	13	76.53%
pylint/checkers/variables.py	22	96.61%
pylint/lint/pylinter.py	23	94.9%

Totals
Change from base Build 2439119251:	-0.01%
Covered Lines:	16334
Relevant Lines:	17100

---

💛 - Coveralls

[Pierre-Sassoulas]

I think it would be nice to add the generated file(s?) to the repository (as we did for the messages list) in order to see what changed because the review is really hardcore otherwise 😄 We could auto-update them for release with tbump too. What do you think ?

[DanielNoord]

I think it would be nice to add the generated file(s?) to the repository (as we did for the messages list) in order to see what changed because the review is really hardcore otherwise 😄 We could auto-update them for release with tbump too. What do you think ?

Agreed! But perhaps let's do that after the current rework is done? I was quite happy this PR was under 100 lines and I tend to look at the final output in RTD anyway when reviewing these PRs.

[Pierre-Sassoulas]

I was quite happy this PR was under 100 lines

Yeah sure this PR is quite elegant 😄 We don't have to ruin it though, we can add the generated file from another one and rebase on main when it's merged. It's just a lot harder to check everything when you need to compare two HTMLs side by side instead, of a a git diff on .rst code then check the modified HTML visually. Do you want me to add the generated file in another PR ?

[DanielNoord]

Do you want me to add the generated file in another PR ?

Yeah, but I would wait with adding the generated file right now. It's just more stuff we potentially need to move around during the renaming process. We shouldn't really need to touch these generate files at this point anyway 😄

[Pierre-Sassoulas]

OK then let's do #6589 first.

[Pierre-Sassoulas]

Opened #6678 regarding the generated rst added to the repository.

[Pierre-Sassoulas]

I was going to suggest a function but it's easier if I do the commit directly.

[Pierre-Sassoulas]

(Beside we can check that the refactor is not changing the behavior easily as we have the full generated output in the repo)

[Pierre-Sassoulas]

Found an issue when the default value is the current interpreter in all-options.rst:

-**Default:**  ``(3, 10)``
+**Default:**  ``(3, 8)``
-   py-version = [3, 10]
+   py-version = [3, 8]

My interpreter is 3.8, yours is probably 3.10 :)

[DanielNoord]

Found an issue when the default value is the current interpreter in all-options.rst:

-**Default:**  ``(3, 10)``
+**Default:**  ``(3, 8)``
-   py-version = [3, 10]
+   py-version = [3, 8]

My interpreter is 3.8, yours is probably 3.10 :)

That should probably be fixed in a follow-up PR. We need to special case it I guess... Annoying 😓

[Pierre-Sassoulas]

On the plus side we detected the problem, adding the full output has its perks 😄

[Pierre-Sassoulas]

I want to add link between section, I think we'll need to do a refactor first. There's issue with the doc generation because we have a string for the checker name instead of the checker so it's hard to do the right ref between extension and standard checker. I can push the work in progress if you're interested or simply want to understand what I'm talking about 😄

[DanielNoord]

I want to add link between section, I think we'll need to do a refactor first. There's issue with the doc generation because we have a string for the checker name instead of the checker so it's hard to do the right ref between extension and standard checker. I can push the work in progress if you're interested or simply want to understand what I'm talking about 😄

I understand what you are talking about, but wouldn't :ref:`checker_name Checker` work?

Anyway, let's merge this PR first and do follow-ups. This already has 1500 changed lines 😅

[Pierre-Sassoulas]

Suggested change

	result += f":ref:`See the description of the checker itself <pylint.extensions.{checker}>`.\n\n"
	result += f":ref:`See the description of the checker itself <pylint.extensions.{checker}>`.\n\n"

Here with a string we can't know if the checker is a pylint extension or a standard checker.

[DanielNoord]

This is another problematic default value. I'm starting to doubt whether we should in fact include these generated files...

[Pierre-Sassoulas]

It's not really problematic if the generated file change a little (In fact I could have avoided adding this by doing a partial add). The fact is it permits to see the doc depends on the generator's operating system which it should not, so imo it's a good think that it makes problem apparent. (We can fix it later, should be something like "depends on your operating system" or "default to your current interpreter").

[Pierre-Sassoulas]

Anyway, let's merge this PR first and do follow-ups

We're removing the information from the page so we should probably add a link to where the information are at, right ? Otherwise it's really hard to find the option / message generated.

(I thought of a follow-up where I'd add the link the to the message overview in the message list of the extension page)

[DanielNoord]

Anyway, let's merge this PR first and do follow-ups

We're removing the information from the page so we should probably add a link to where the information are at, right ? Otherwise it's really hard to find the option / message generated.

(I thought of a follow-up where I'd add the link the to the message overview in the message list of the extension page)

Hm, then we should probably split some of the work here. Perhaps by adding the links first? I'm losing track of the refactors, added TODOs and actual changes that are in this PR.

[Pierre-Sassoulas]

Hm, then we should probably split some of the work here. Perhaps by adding the links first?

Let me open a pre-refactor MR :) !

[DanielNoord]

Btw, perhaps we should draft this and focus on the changelog changes so we can release 2.14?

[github-actions]

🤖 According to the primer, this change has no effect on the checked open source code. 🤖🎉This comment was generated for commit 501fa08

[Pierre-Sassoulas]

I think we need to add a link to the option page of the checker, did you try :ref:`checker_name Checker like you suggested earlier ? I'm going to continue working on the doc for some time. Mainly links between section for easier navigability.

[Pierre-Sassoulas]

Look neat ! I have a suggestion for the text of the link, let me know what you think.