add an option to not automatically generate classifier

[deronnax]

Hello.
I set up pyproject-fmt for some of our projects which are apps, not libraries, not meant to be upload to PyPI, and I find the classifiers automatic generation unwanted for our case. It doesn't make sense for a private app to have PyPI classifiers. I would like an option to turn their generation off.
I can do the PR if you are OK with this.
Cheers.

[gaborbernat]

I'm trying to limit the number of knobs this tool has, and this feels one of those that would be of little benefit and expand our API. What's wrong with adding the classifiers? It will not hurt your app 🤔

[deronnax]

It could, I think, confuse a reader of the pyproject.toml in a hurry that the project is a package (plus some bit of useless git noise each time the supported python version is changed).

[gaborbernat]

Classifiers are not useful only for libraries, they are IMHO valid for applications too. Classifiers are just metadata explaining traits of the app, the way I see it.

[deronnax]

They are valid but useless. Outside of the PyPI (which I never seen anybody use its classifiers), they are a fragile plagiat of the python-requires, which on the contrary is an actual meaningful hard information. I never watch classifiers because they don't have to be correct and most of the time they are not.

[deronnax]

Yesterday I had an error message from pyproject-fmt complaining that it did not find tox in the path. I did not get why pyproject-fmt was complaining about a missing tox and I thought my python installation was broken so I spent dozen of minutes checking stuff and after a while, I learnt that pyproject-fmt needed tox in the path to generate its classifiers.
It makes double-down that this behavior is very specific to some use-case and should be able to disabled, if not disabled by default and expressively asked for.
Most python non-open source applications will not have tox in the path, because they target only one python version.

[gaborbernat]

PR for this would be welcome 👍

[deronnax]

please assign this issue to me :)

[gaborbernat]

@deronnax still planning to do this?

[henryiii]

I’d recommend a —-max-supported-python flag (or similar name) also supporting auto (current behavior, default) and none, which means the classifiers are not touched.

[gaborbernat]

I’d recommend a —-max-supported-python flag (or similar name) also supporting auto (current behavior, default) and none, which means the classifiers are not touched.

I'm not a fan of this, I'd rather have an off flag that would remove version classifiers if present at all.

[deronnax]

@gaborbernat I plan to do it whenever I find the time, but if someone want to do it before me, be my guest.

[henryiii]

But how do I control the classifier range? I tried pyproject-fmt on a project, and it's stripping out the 3.13 classifier when I add it. For setup-cfg-fmt, there was a flag you could set to control the maximum classifier. I don't want it stripping classifiers I support, or adding classifiers I don't support. How do I control the upper limit without a setting?

[gaborbernat]

https://pyproject-fmt.readthedocs.io/en/latest/#configuration-via-file should be documented there

[henryiii]

I didn't know about that, perfect, thanks! This is better than a CLI flag.

[gaborbernat]

🤔 Maybe this should be in bold characters.

[henryiii]

I think might be just because I am familiar with the project from before it had this option. :) This was very different last I read it: https://pyproject-fmt.readthedocs.io/en/latest/#python-version-classifiers - it discussed tox then.

[gaborbernat]

Yeah just got reworked with version 2, we no longer use tox to calculate the max version.