pyproject.toml (PEP 518) support

@valignatev

In GitLab by @valignatev on Jun 11, 2018, 10:58

Hi! Is there a plan to support pyproject.toml from PEP 518?
Specifically, it would be nice if flake8 could understand [tool.flake8] section in the pyproject.toml file.

@jgirardet

In GitLab by @jgirardet on Jul 28, 2018, 06:04

Hi,
I'm ok to do it.
I have a question for maintainers concerning the toml thing, which way would you like it to be implemented ?
some possibilities:

add a toml libray to flake8 dependency, which one (toml, tomlkit, other)
only use pyproject.toml if a toml libray is importable (which would let to the user to add a toml lib in his requirements. still the question, which toml libray would we support ?
simply parse the pyproject.toml to extract the [tool.flake] section and deal with. not the best, probably not every usecase, but could be enough.

As simple implementation, all those possibility should return a dict to add to a configPArser.

Thank for your advice.
Jimmy

@valignatev

In GitLab by @valignatev on Jul 28, 2018, 07:22

I'm nobody, of course (in the terms of flake8 project), but I personally think that pyproject.toml should be the first-class citizen since it's in the PEP. So the first option.

@tmose1106

In GitLab by @tmose1106 on Jul 29, 2018, 11:58

I am also not affiliate with flake8 in any way, but here is my two cents:

At the moment, is hard to tell which toml library to choose. As of today I have found the toml library to work just fine for parsing. It is also worth noting that if poetry picks up usage in the future, tomlkit could very well become the dominant toml library.

Specifically to @jgirardet's question, I feel that the second option would make the most sense at the moment. Simply make the toml library an optional dependency and if there is a pyproject.toml file present, use it. I feel that the first option can be best handled as a future feature request once the dust has settled some more on poetry adoption so that we can make an informed choice on a mandatory toml library dependency and phase out some of the other configuration methods.

@jgirardet

In GitLab by @jgirardet on Jul 30, 2018, 03:47

mentioned in merge request !245

In GitLab by @d_ on Jan 30, 2019, 02:38

mentioned in commit d_/dlc-gui@248a6b88d5d620dac793b7856fc217b0e1210e5d

In GitLab by @d_ on Jan 30, 2019, 02:50

mentioned in commit d_/dlc-gui@ba4aadd9fccb0568c8712321c664fa83a7bca36a

@radek-sprta

In GitLab by @radek-sprta on Feb 28, 2019, 24:56

A temporary solution could be what tox did -- just inline the ini configuration under tool.flake8.legacy_flake8_ini key.

@asottile

In GitLab by @asottile on Feb 28, 2019, 07:37

@radek-sprta iirc tox did that because they use a special ini parser with extra features (substitutions etc.). Doing that for flake8 wouldn't really help (you'd still need toml to parse that)

@rossmacarthur

In GitLab by @rossmacarthur on Mar 27, 2019, 03:26

I would really like this to be done 🙏, I don't mind working on it.

@jgirardet @tmose1106 my opinion is to use the toml library it seems to be much more widely used than tomlkit (based on https://pypistats.org) and we don't need the style preserving that tomlkit offers.

I don't think pyproject.toml support should be a feature/optional dependency because it's in the PEP.

@asottile

In GitLab by @asottile on Mar 27, 2019, 08:31

I don't think pyproject.toml support should be a feature/optional dependency because it's in the PEP.

Just want to point out that both of the "pyproject.toml PEPs" (517 and 518) are about defining a build system for pip and aren't speccing that projects should stuff configuration in there (PEP 518 briefly mentions the tool table but is referring to configuration of PEP517/PEP518 build tools). See also this thread from pypa/pip further about that topic.

In GitLab by @d_ on Mar 30, 2019, 13:13

mentioned in commit d_/dlc-gui@74b0d42bdfb742217720dc2d806d2fbbcda93341

@ethanhs

In GitLab by @ethanhs on May 15, 2019, 15:30

FWIW, I read the PEP as allowing configuration of any tool, and asked on the packaging discourse. Based on https://discuss.python.org/t/pep-518-clarify-scope-of-tool-section/1682/2 I think it is safe to say that all tools are allowed in pyproject.toml, and it isn't meant just for build tools.

@sigmavirus24

In GitLab by @sigmavirus24 on May 18, 2019, 11:11

@ethanhs As I understand Anthony's comment, he was responding to the assertion that Flake8 should grow this because the PEP allows for tools to use the file. The PEP doesn't require tools to use pyproject.toml and thus the assertion that "it's in the PEP" doesn't make sense.

If Flake8 were a tool like homebrew or pip that could reasonably report usage to us, we could say "Well we can deprecate X, Y, and Z because no one is using it to allow for the surface area to expand to supporting pyproject.toml." As it is, we have a poor understanding of what's used, what isn't, and what makes sense to adopt.

I don't think anyone is saying "pyproject.toml" is out of the question. It's just a matter of the fact that the existing configuration processing in Flake8 is ridiculously complex because of historical reasons and backwards compatibility. I would feel far more comfortable (if I were still the primary Flake8 maintainer) if I could deprecate a bunch of the config related things before adding support for another file.

Further, while there hasn't been an explicit "yes" or "no", I'd like to remind everything that "No is temporary, but yes is 'forever'" as far as any responsibly maintained project is concerned. In other words, given our existing attempts to provide backwards compatibility, it's entirely likely that we'd never be able to get rid of this once it was added. That's a long term maintenance nightmare, sadly.

@Stavros

In GitLab by @Stavros on May 27, 2019, 10:33

If Flake8 were a tool like homebrew or pip that could reasonably report usage to us

Why can't it? I'd opt in.

It's just a matter of the fact that the existing configuration processing in Flake8 is ridiculously complex because of historical reasons and backwards compatibility

Is there not, essentially, an order with which ini files are processed? If so, adding one more file to that list doesn't sound terrible, although I do see your argument about having to then maintain that for ever...

@jgirardet

In GitLab by @jgirardet on May 27, 2019, 12:09

Initially I thought it was great to add it then I started !245.
Only one config file for everything : config, build system, packaging, third party tools : a dream ❤️

And I read the opinion of Guido in rejecting pyproject.toml support in mypy : python/mypy#5205

Maybe he is right. Maybe old tools should keep .ini support and don't bother pyproject. Maybe only new tools should try to support pyproject.toml and ignore .ini files (this is what black did).

So I will not go further for now in !245. I think we should close !245. But if maintainers really want to add it, I'll then finish the job.

@erikkemperman

In GitLab by @erikkemperman on Feb 28, 2020, 06:04

Thanks for the quick response!

Ah, that may be a different pip issue than the one I thought you were pointing out above. I assumed you were thinking of pypa/pip#6163 -- which was why mypy, for example, got rid of their pyproject.toml (and reinstated it as this pip issue was fixed). Sorry, my mistake!

It seems to me that the presence of pyproject.toml signals (to build tools and installer) that you want to follow PEP517. In that case, it seems reasonable to me that if you need a dependency during build (such as six in your example) it ought to be listed as such in the toml file. From that point of view, the stack trace you quote does not surprise me.

After all, explicit control over build-time dependencies was kind of the point of the PEP. Pip has an option to disable it (even in the presence of pyproject.toml), and the above works as expected if I add it:

$ pip --version
pip 20.0.2 from /home/erik/Workspace/tmp/x/venv/lib/python3.8/site-packages/pip (python 3.8)
$ pip freeze
six==1.14.0
$ cat setup.py 
import six  # problem?

from setuptools import setup
setup(name='foo')
$ touch pyproject.toml
$ pip install --no-use-pep517 .
Processing /home/erik/Workspace/tmp/x
Installing collected packages: foo
    Running setup.py install for foo ... done
Successfully installed foo-0.0.0

Likewise, things work fine if I don't use that flag but add six as a build dependency:

$ cat pyproject.toml
[build-system]
requires = [
    "setuptools >= 40.6.2",
    "wheel >= 0.30.0",
    "six >= 1.14.0"
]
build-backend = "setuptools.build_meta"
$ pip install .
Processing /home/erik/Workspace/tmp/x
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: foo
  Building wheel for foo (PEP 517) ... done
  Created wheel for foo: filename=foo-0.0.0-py3-none-any.whl size=949 sha256=63d3d07ae7ba7502d7989069a893b9dfe81e27cef29a1edfa0ceebcf32243ac0
  Stored in directory: /tmp/pip-ephem-wheel-cache-ul368612/wheels/88/6b/e1/5b8303670d53117429bfb7cc3c6fb62920567ac8b224865e24
Successfully built foo
Installing collected packages: foo
Successfully installed foo-0.0.0

I don't believe anyone is proposing that flake8 (or anyone else) should support reading its configuration from pyproject.toml in projects which otherwise do not follow PEP517... Or are they? So I guess I'm now not entirely sure what problem you are expecting this to cause for users (and maintainers) of flake8.

Please don't get me wrong, I don't mean to be contrary for the sake of it. Just trying to figure out if I understand the objections properly. Thanks again for taking the time to respond -- and for maintaining this great package!

@asottile

In GitLab by @asottile on Feb 28, 2020, 07:06

sorry in case it wasn't clear, six is just an easy demonstration of the issue -- there are situations where an isolated build is not possible and presence of pyproject.toml forces you into isolated build with no opt-out

@intgr

In GitLab by @intgr on Feb 28, 2020, 07:55

That pip behavior is surprising and a caveat for pyproject.toml in general, for sure. But it's not actually a blocker for adding pyproject.toml support into flake8 right?

@asottile

In GitLab by @asottile on Feb 28, 2020, 08:00

it is: the list of blockers

more specifically because we cannot in good faith deprecate and remove the other configuration options

@FallenWarrior2k

In GitLab by @FallenWarrior2k on Feb 28, 2020, 08:08

Is there a need to deprecate other options, and if so, why? As far as I know, most other tools that support pyproject.toml haven't deprecated support for setup.cfg, tox.ini, or their own config files.

@asottile

In GitLab by @asottile on Feb 28, 2020, 08:13

the reasoning is covered above, but it's not surprising that one hasn't read this enormous thread

the tl;dr is that the configuration parsing is some of the most tangled code in flake8 and adding more complexity and more ways to do something is not desirable

@rpdelaney

In GitLab by @rpdelaney on Feb 28, 2020, 11:16

You give good reasons why it would benefit flake8 to do this (culling tangled incomprehensible config parsing code), but dropping support could also be a long-term benefit to the entire ecosystem if publicized well and in advance. The plethora of ancient, broken configuration options won't die in part because tools like flake8 continue to support them.

@erikkemperman

In GitLab by @erikkemperman on Feb 28, 2020, 12:57

The plethora of ancient, broken configuration options won't die in part because tools like flake8 continue to support them.

That's just unfair. I for one would like to see this supported, obviously, but it's completely understandable -- not to mention correct -- that maintainers of such a widely used package be very reluctant to change such a fundamental component.

And please note that I just wanted to throw something concrete out there, and demonstrate some goodwill perhaps, in updating the original merge request -- in no way am I proposing that anything change imminently.

Maybe some untangling would be in order first, before configuration formats can be factored in or out more comfortably. That's probably no small task.

@rpdelaney

In GitLab by @rpdelaney on Feb 28, 2020, 13:15

That's just unfair. I for one would like to see this supported, obviously, but it's completely understandable -- not to mention correct -- that maintainers of such a widely used package be very reluctant to change such a fundamental component.

I'm not sure what you take my point to be, but to be clear, I understand the tension also. It is by no means easy to drop support for old things in a widely used app, nor is it obvious that that is the right thing to do here. But to build a case that it is the right thing to do, I think it's worth acknowledging the costs of maintaining legacy support indefinitely and without a planned (and publicized!) EOL timeline. The situation with the config parsing will either only get worse, or it will continue to sacrifice support for newer, better things in the name of maintaining the old things. I don't think that's sustainable.

@erikkemperman

In GitLab by @erikkemperman on Feb 28, 2020, 13:39

I'm not sure what you take my point to be, but to be clear, I understand the tension also.

Sorry if I've read too much into the sentence I quoted; it seemed to me maybe slightly accusatory. Glad to be wrong.

@rpdelaney

In GitLab by @rpdelaney on Feb 28, 2020, 20:04

I think I see what you mean. I'm not intending to lay blame for the array of packaging standards at the feet of flake8: not even for the spaghetti of parsing code required to support all of them. It did not get this way because of any decision made here. But I do worry that a pattern of unwillingness to design exit strategies across the ecosystem has contributed maintaining these difficult tensions. So I don't want to lay blame, but I do want to call attention to the way that worries about backward-compatibility with breaking configuration changes can unintentionally contribute to the maintenance of the dysfunction.

If flake8 were to, after a reasonably protracted and publicized time period, drop support for .flake8 / setup.cfg / etc in favor of pyproject.toml, no doubt there would be some grumbling. But it would also add momentum to the shift elsewhere and encourage others to "go with the flow". That might be a good thing.

The key, I think, is the well-thought out and well publicized migration plan. First, we need to have one. Second, it needs to give people ample time to find out that the migration is planned, and adjust. I worry that @asottile and others might think that this is something that has to happen in 1 day with no advance notice except an open PR on this gitlab repo, but that doesn't have to be the case at all. There is a lot that can be done to make the transition less painful. Not painless, but the pain can be mitigated.

As for pip, it seems like pip's support of PEP517 may be incomplete. I'm not sure how best to improve that, or what kind of levers would have to be moved. But flake8 need not be blocked by it.

@asottile

In GitLab by @asottile on Feb 28, 2020, 20:27

or we have zero pain by not migrating. look, I've stated what needs to happen above for this to even be considered -- until those two things change this is not happening. I understand this isn't a popular choice.

if you'd like to continue this discussion please reach out to me privately, you may find the email address in my git commits

there's been an uptick in those that cannot follow directions (NOTE: if you ask about pyproject.toml your issue will be closed as a duplicate of #234) so I will reiterate here:

both of the things above are blockers before we'd even start considering an implementation

only one of two of them has been resolved -- there is a tomllib in the stdlib as of python 3.11.

the other has not (pip still has different behaviour based on the presence of pyproject.toml)

if you'd like to continue this discussion please reach out to me privately, you may find the email address in my git commits

Migrate configs for isort, mypy, and pytest into pyproject.toml (#10844)

Navigation Menu

Repository navigation

pyproject.toml (PEP 518) support #234

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

pyproject.toml (PEP 518) support #234

Description

Activity

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

22 remaining items

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Apr 3, 2021

asottile commented on Aug 5, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions