pyproject.toml configuration support #447
Comments
|
As far as I know, there's 1 formatting/style tool that supports it. What other tools have added support for it? For what it's worth flake8 and pycodestyle have both refused to support this at this time. |
|
That's interesting, I hadn't interpreted PyCQA/pycodestyle#813 as a refusal, rather than just a deferral until wider config refactoring happened. |
|
A very vocal minority are trying to create that impression in my experience but they have no regard for backwards compatibility or the maintenance burden of each of these tools adding yet another new config file location to have to observe and determine precedence of. @wlcx that is de facto refusal because no one is actually working on pycodestyle |
|
Understood, thanks for elaborating. |
|
@sigmavirus24 It seems that in 2020 |
|
@prokher given the accuracy of the title of the section "Projects discussing the use of pyproject.toml" which conveniently implies that those projects are still open to the idea, I'm not swayed by that list. It's not overwhelming in size. The benefits of adopting pyproject.toml (as I've explained in numerous places) are not overwhelming in anyway and finally as I've said above, the biggest barrier is lack of maintainers who can work on it without breaking things for existing users. |
|
+1 for this |
|
I am happy to reopen the issue at the very least since it seems like there are some discussions going on. |
|
+1 for this I have a project where I am using black, isort, pylint, coverage and pytest and have configured all of them within the [tool.isort]
multi_line_output = 3
include_trailing_comma = true
force_grid_wrap = 0
use_parentheses = true
ensure_newline_before_comments = true
line_length = 88
[tool.pylint.format]
max-line-length = 88
[tool.pylint.messages_control]
disable = ["C0301", "C0330", "C0326", "C0415"]
[tool.pytest.ini_options]
DJANGO_SETTINGS_MODULE = "config.settings.test"
[tool.coverage.paths]
source = ["src", "*/site-packages"]
[tool.coverage.run]
branch = true
[tool.coverage.report]
show_missing = true
fail_under = 100It would find it really useful to be able to also define a |
|
It is possible to use Also, @sigmavirus24, it isn't a vocal minority - PEP518 standardized the usage of I am normally of the "standards are a poor excuse for mediocrity" stance, however, |
|
It's a standard for build tools with an allowance for extraneous tools. The tools that can support it without serious maintainer burden have chosen to do so. The rest that have limited or no maintainer time shouldn't. The people talking this up are over-selling the standard (like you are) for ad hominem purposes. This conversation and issue has been pointlessly circular as users demand things maintainers can't afford to support. |
|
Please don't go burning yourselves out for this! If it's too much load and maintainer time is so scarce, I think people will understand. Heck, perhaps someone who cares enough will help and ease that load. I doubt it's anyone's intention to attack the maintainers of |
|
The people talking this up are over-selling the standard (like you are) for
ad hominem purposes.
Nobody's overselling anything, nor is any ad hominem involved. Do you
know what that means? I haven't personally attacked any of the
maintainers anywhere, because that's not part of computer science.
If you do a little bit of thinking you'd realize that the
standardisation makes life easier, as it means you don't need to
maintain the processing for your own configuration file.
This conversation and issue has been pointlessly circular as users
demand things maintainers can't afford to support.
Nobody has demanded anything, either. This is a discussion - if you
don't know what those are, they're also quite common in science.
Perhaps something you should invest a little portion of your free
maintainer time into is respectful tone and ability to work with
rational conversations. Just a suggestion.
that's all, I think
Absolutely correct. Just trying to help and be constructive.
Either way, in reasonable terms, supporting it shouldn't be too much of
a hassle. If anything, as aforementioned, it allows the developers to
shave off the overhead involved in supporting individual configuration
formats.
I am open to making a PR and contributing if necessary. If not, that's
my piece said.
|
|
Actually, another interesting thing I noticed - isort, also under PyCQA, does support |
There is an ad hominem throughout this issue "This is a standard and must be implemented everywhere" (not an exact quote). It's not an ad hominem character attack on the maintainers, it's a claim repeated over and over and over to get your way. It's not you in particular doing this but you in particular piling on to this. That's the definition of an ad hominem. Quoting Wikipedia:
In other words, claiming that the PEP that defines the file and allows for tools to leverage
I didn't say you personally attacked anyone. You misread my words.
You ask me to be "more respectful" but have now taken a quite emotional approach to trying to attack me for being:
None of which is very respectful in and of itself. Please point out exactly how I was disrespectful.
I suspect in "computer science" (of which you speak as if you're an expert) you just drop support for things haphazardly. That's not how real software maintenance works. "It shouldn't be too much hassle" exposes your inexperience in supporting a widely used tool or set of tools and doesn't take in to consideration the complexities of existing software.
I believe it's been said numerous times above that the maintainers don't have the time/energy for this, and still we have folks adding comments that add no new content and continue to repeat false statements. If there ever was an appetite for doing this work, simply explaining to people the current state of affairs takes a quite significant amount of time away from even doing that work. This issue has been open for over a year, no one has said "I'll help do this work" and then kept with it as soon as they realized the complexity of implementing it. |
|
Sorry to hear that man, I really meant to say something nice. It's painful to see this conversation devolve this way, and to hear such a pessimistic viewpoint - as justifiable as it may be. But I recognise my comment wasn't really adding to the technical conversation. I hope you and the other maintainers get some rest 🌴 |
@sigmavirus24 No offence, but I am pretty sure that "ad hominem" does really mean "an argument based on the character of the opponent". The
And from my understanding the
part is simply a statement of fact and not the definition. All the dictionary entries I can find also seem to agree, that "ad hominem" means either an attack on the character of the opponent or an appeal to prejudices. Wikitionary, Merriam-Webster, Dictionary.com. Although, it's possible that I'm wrong. English is not my first language, so I might be mistaken in this case. As I see it, @Nytelife26 first comment was a fairly reasonable and polite argument, attempting to refute the (possibly) outdated notion that this feature would only be useful to a small group of users. While something being a part of a PEP is not a good argument for it being good, it is a good argument for it not being an unpopular or fringe use case. If it has a PEP and is implemented in at least 5 major tools, it's at least big enough to have a civil discussion about. I agree with you, that his second comment is not very polite to say the least, but it's not like his reaction is completely unprompted. As I see it, his outburst was triggered by the following part of your comment:
From his point of view, he came into this issue to have a civil discussion, but was immediately accused of making a personal attack (maybe you didn't mean that, but that's definitely how he understood you). I would once again reiterate that he could have replied in a more polite of a manner, but from a "who shot first" perspective, you can't blame him too much.
No. As pointed out by other people in this issue, nobody is demanding anything. This is (AFAIK) an open source project. We are (trying) to have a discussion about whether this feature is worth your (and our, as a community of contributors) time and effort. Every person who leaves a comment on this issue or even just thumbs up the OPs comment is simply voicing their opinion. I don't think that anybody in this thread has come here with bad intentions (like maliciously inflating the public perception of the support for the People are offering their help with implementing this feature. People are giving arguments for and against this feature being implemented (developer and maintainer effort being part of this discussion). This is how Open Source is supposed to work, no? |
|
Although, it's possible that I'm wrong. English is not my first
language, so I might be mistaken in this case.
You are not. That was precisely my point - not that it makes my argument
any more valid, but English *is* my first language, and linguistics is
one of my subjects of interest.
Ad hominem, under the Oxford Languages dictionary, refers to an argument
directed against a person rather than the position they are maintaining.
Nobody in this thread personally attacked anyone, which is what I was
saying - especially not me, which is, as far as the context was
concerned, who he was responding to.
something being a part of a PEP is not a good argument for it being
*good*, it **is** a good argument for it not being an unpopular or
fringe use case.
Absolutely. "Standards are a poor excuse for mediocrity", as I always
say, *however*, they are useful for unification.
his second comment is not very polite to say the least
[...]
From his point of view, he came into this issue to have a civil
discussion, but was immediately accused of making a personal attack
Pretty much. While I agree that, looking back on it, my response was
somewhat irrational, I cannot express the degree of annoyance it causes
me for someone to bring a victim mentality and the notion of ad hominem
into a civil discussion regarding engineering where they have no place.
Those things do not belong in science. Ever. And I will not stand to
have such accusations made against me or any other innocent people.
People are offering their help with implementing this feature. People
are giving arguments for and against this feature being implemented
(developer and maintainer effort being part of this discussion). This is
how Open Source is supposed to work, no?
Thank you for your response. I didn't respond because arguing wouldn't
take it any further, and I already said I'd be willing to make a pull
request. But yes, people are most certainly willing to help.
Although, that does bring one thing to my attention. The tool *can
already read TOML configuration* (mostly) due to its similarity to `.cfg`,
as I highlighted earlier in the thread. It just doesn't fully or officially
support it, and it doesn't use the correct configuration header format for
`pyproject.toml` files.
Therefore, it would not be overly complex. I cannot weigh in on the
usage and need to support `tox.ini` and `setup.cfg` as I am not aware of
any formal studies or statistics on their usage, but I know adding
`pyproject.toml` would not be overly difficult (once again, TOML is a
close superset of CFG).
|
@Nytelife26 I've tried it and for my project configuration files it failed, when trying to parse an unrelated part of the configuration. Unfortunately With that said, I do agree that it shouldn't be too complicated. It's not "just enable it, lol" simple, but more like "write a thin wrapper around I don't know, how close of a superset After that, adding the |
We aren't repeating claims, we're making points that relate to the discussion. It feels repetitive because it has been going on for quite some time.
Your words were "The people talking this up are over-selling the standard (like you are) for ad hominem purposes". Notice the "(like you are)". You are implying that I, too, am engaging in ad hominem, and simply overselling a standard. Do I misread or do you miswrite?
"avoids genuine debate by"
Nobody has to - but your organization already has implemented support for it in its other projects. That alone proves that it can be done and it is not too complex or unmaintainable. If you genuinely believed it was, you would not have already done it.
I do still stand by those statements. Ad hominem and related fallacies belong nowhere near informatics, science, or related fields. It is also important to note that this is a discussion, not a demand.
"This conversation and issue has been pointlessly circular" Not once did I say real scientists are robots - I didn't even mention them. However, those definitely have undertones. They are not simply observations. They are passive aggressive at best. That is the reasoning for the response I gave you.
You gave me a passive-aggressive comment with no constructive value, I gave you a reality check. The law of equivalent exchange.
See the above. Once again, I am done discussing the semantics of language and respect, though. I will not be partaking in further discussion of these things.
It isn't haphazardly at all; versioning exists solely so you can make changes while informing existing users of the changes you make in upcoming releases, deprecations included, and so current users are not affected by your changes in future releases until they choose to update.
It does, because it would reduce the complexity of the existing software, were you to deprecate other formats. Once again, though, I am not sure of their usage rates, so I am uncertain of how appropriate that solution would be.
Once again, that is provably wrong. If you can do it in other projects, you evidently can do it.
No false statements have been made, nor are there comments adding no new content. We are simply making points, and backing them up. That's as good as content gets.
I said it earlier, as have other people. A resolution needs to be achieved before effort is put into creating an implementation, though - nobody will work on something to later be told it is not happening. Apologies, I thought it was due time for a formal response. If you want someone to work on this, let me know. Until then, I will not be participating in anything on this thread other than critical discussion points and the overall verdict. |
I know - TOML is a superset for the most part (of CFG), not a subset. It supports basics, but special types are off the table thus far.
That sounds like a good idea. I haven't delved too much into the configuration system used by
It would be better to use an actual TOML parser honestly. We'll see if this gets approved.
Thank you for your contributions. |
|
Consider me nerd-sniped, I've implemented |
|
Thanks for the work @RuRo 👍 In what version will this be available ? |
|
Just to make it clear, on version 👉 [pycodestyle]
max-line-length = 100👉 command: pycodestyle /path/to/file.py --config=pyproject.toml |
Many other python formatting/style tools have added support for the
pyproject.tomlfile's[tool.*]sections for their configuration. Is this something that pydocstyle would be open to supporting?The text was updated successfully, but these errors were encountered: