[configuration doc] Add the '--generate-rcfile' option

[Pierre-Sassoulas]

Type of Changes

	Type
✓	📜 Docs

Description

Follow-up to this stackoverflow question: https://stackoverflow.com/questions/72877687/pylint-where-is-the-pylintrc-documentation

[DanielNoord]

We have deprecated the functions used for --generate-rcfile internally. I know we didn't reach a decision last time, but weren't we thinking of nudging users towards .toml files? They are more easily parseable anyway and are becoming the standard within the ecosystem.

[coveralls]

Pull Request Test Coverage Report for Build 2621274801

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 95.359%

---

Totals
Change from base Build 2618496511:	0.0%
Covered Lines:	16705
Relevant Lines:	17518

---

💛 - Coveralls

[Pierre-Sassoulas]

Hmm yeah, but maybe we should still add the command in the doc so if someone really want an ini file we do not get an issue/question for it ? For example flake8's really hell bent on not using pyproject.toml right now.

[DanielNoord]

Hmm yeah, but maybe we should still add the command in the doc so if someone really want an ini file we do not get an issue/question for it ?

Yeah, I'm not opposed to it. We can just issue a warning about it on 3.0 and make the internal function private. Something like:
You can still use this command but it is no longer maintained

For example flake8's really hell bent on not using pyproject.toml right now.

This issue is almost fixed I think. setuptools has a beta in which most of the original issues have been solved 😄

[Pierre-Sassoulas]

Something like: You can still use this command but it is no longer maintained

Yeah it would make sense to deprecate some configuration options, right now there's a lot to keep backward compatible. I think there's a lot to discuss on this issue though. (I don't think we can deprecate ini before auto-upgrade of configuration, do we support something else than pyproject.toml or only that...).

[DanielNoord]

Yeah it would make sense to deprecate some configuration options, right now there's a lot to keep backward compatible. I think there's a lot to discuss on this issue though. (I don't think we can deprecate ini before auto-upgrade of configuration, do we support something else than pyproject.toml or only that...).

We currently support anything that looks like an .ini or .toml file that has some form of pylint configuration in it.
pylint-config can already be used to auto-upgrade as it takes your current configuration into account. Running it from within a directory with a pylintrc and choosing toml should create a .toml file based on that previous file.

[Pierre-Sassoulas]

pylint-config can already be used to auto-upgrade as it takes your current configuration into account.

Damn, you're right I forgot that. Should be documented there, ain't it ?

[DanielNoord]

Probably 😄

But since pylint-config is very barebones right now I haven't put much effort in its documentation just yet.

[Pierre-Sassoulas]

Hmm right, I also forgot that.

[Pierre-Sassoulas]

By the way as the generate toml config take the current configuration into account doesn't it do that too ? I suppose it also use the right terminology and not the deprecated argument ? (Isn't a big part of #5462 already done ?)

[DanielNoord]

By the way as the generate toml config take the current configuration into account doesn't it do that too ? I suppose it also use the right terminology and not the deprecated argument ? (Isn't a big part of #5462 already done ?)

Yeah I think so. But we don't have many test cases so it would be good to add some more and see if they work.