pyproject.toml (PEP 518) support #234

Open asottile opened 3 years ago

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.

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

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.

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.

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

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.

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)

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

I would really like this to be done :pray:, 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.

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

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.

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.

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...

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 :heart:

And I read the opinion of Guido in rejecting pyproject.toml support in mypy : https://github.com/python/mypy/issues/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.

In GitLab by @olibre on Jun 14, 2019, 01:40

Hi @jgirardet

Guido said in August 2018:

PEP 518 doesn't say that all build/test requirements must use pyproject.toml for their own configuration. It only says that the list of packages to be installed must be specified there (as opposed to in a parameter to the setup() call in setup.py).

But his opinion is changing over the time. For instance, Guido rejected the idea of dict_a += dict_b some years ago, but he was recently seduced by that shorthand PEP 584. What I mean is that Guido mind may change on that subject.

In my case, having the configuration stuff of my Python tools in one file will clean my source code root directory. Multiple configuration files polluting the source code directory is not pleasant, isn't it?

In GitLab by @jokerjokerer on Jun 15, 2019, 03:04

It's always a trade-off though and depends on the size of that file:

one configuration file with 100 lines is probably better than 5 files with 20 lines; however three files with 100 lines each is probably better than one file with 300 lines :thinking: putting all config in pyproject.toml soon gets you to large unmanagable config file :thinking:

In GitLab by @olibre on Jun 16, 2019, 09:07

You are right @jokerjokerer ...

In GitLab by @aiguofer on Jul 12, 2019, 13:39

I was just in the process of trying to unify my various config files... down to setup.cfg, pyproject.toml and .bumpversion.cfg. Would love to get it all into pyproject.toml though!

In GitLab by @d_ on Aug 18, 2019, 14:16

mentioned in commit d_/dlc-gui@fa5edf6dd433e041a1b00459c8cd45ce1c4fb003

In GitLab by @d_ on Aug 18, 2019, 14:20

mentioned in commit d_/dlc-gui@6e62f9236b0e28f781a439b01c581f0b56b38d3f

In GitLab by @pawamoy on Oct 21, 2019, 13:51

Same here. Last three are .flake8, pytest.ini and coverage.ini. Extensively used packages among the Python community of course, so I understand changes must be done carefully.

One of the main issue when adding support for pyproject.toml is that there's no TOML parser in the standard library yet. Another issue is that while transitioning you need to support two format and multiple configuration file locations. Some people are also reluctant to put everything in pyproject.toml because they have lots of lines in their configuration files.

Despite all this, I still see support for pyproject.toml as a very nice addition/change. TOML values are typed. Python newcomers just have to add a [tool.NAME] section in their pyproject.toml, without needing to read the documentation of each tool to know what file paths are supported. Sometimes these file paths are .ini files, sometimes rc files (not even a proper extension!), sometimes they are dotfiles, sometimes they are not. Sometimes they are directories (looking at you, old isort)!

Plus, once you support pyproject.toml, it's also easy to allow specifying another TOML file to read configuration from. Projects with lots of configuration are then not forced to put everything in pyproject.toml.

Well, I just wanted to share these thoughts. I hope flake8, pytest and coveragepy will support TOML configuration at some point :slight_smile: (could be soon for coveragepy :wink:).

As for those who already added support for pyproject.toml, here is what they did:

tox supports it by allowing users to copy-paste their ini configuration in a TOML multi-line string
pylint supports it by allowing users to specify the same ini keys as TOML [multi]strings
isort completely supports pyproject.toml (types values), granted you install it with an extra: isort[pyproject]
coveragepy is considering using extras as well, or a plugin

In GitLab by @aldanor on Nov 26, 2019, 06:56

@pawamoy Update: coverage now supports pyproject.toml as well as of v5.0b1

The last ones left are flake8 and pytest (and mypy - but they're considering it as well, albeit slowly).

In GitLab by @sigmavirus24 on Nov 26, 2019, 18:45

@asottile We should just deprecate everything else, switch to toml for 4.0 and be done with it. I'll send the PR just to end the ridiculously passive-aggressive comments here

In GitLab by @asottile on Nov 26, 2019, 18:48

lol I'd rather just close + lock to be honest :facepalm: I don't think toml is the way especially with pip continuing to have weird behaviour when the file even exists

In GitLab by @janw on Nov 26, 2019, 23:19

May I ask what weird behavior are you referring to, @asottile? Pip’s logic regarding pyproject.toml is described here and appears to be quite sound and thought-through. Also I might add, as has been argued here, with pyproject.toml being the PEP-designated “way forward” (albeit not strictly for non-build tools), other tools initially implementing support poorly or introducing bugs during the transition should not dissuade the adoption of it. Not even if it’s Pip.

Personally, I wouldn’t take any of the comments made here as passive aggressive, @sigmavirus24. I think people are just offering up firsthand accounts on their move to migrate to pyproject.toml, and making note of the general adoption of pyproject.toml in other projects. This gives you insights on what the collective of project tools is heading towards, and is something worth to consider I think. Even if one is not willing to “lead the pack”, embracing the momentum that’s clearly there is a good thing.

As for deprecating a bunch of things: please do. Nothing requires you to keep maintaining old cruft for years and years over multiple major releases, just to keep everyone happy all the time. I for one greatly prefer dropping things suddenly in the next major release if that makes way for new things, better maintainability, a better tool.

In GitLab by @asottile on Nov 27, 2019, 06:02

@janw

Projects with a pyproject.toml file will use a PEP 517 backend. Projects with a pyproject.toml file, but which don’t have a build-system section, will be assumed to have the following backend settings:

just the presence of the file changes how your project is built -- I can already see the "I can't use flake8 because I can't use isolated builds" issue and then we'll be back to supporting setup.cfg/.flake8 forever (not to mention editable installs still aren't a proper thing for pyproject.toml projects)

toml gives us no benefits over the current format except some people get to delete an extra file from their repository root.

On the downsides, we gain a dependency. There's also additional surface area to support around configuration loading (which we're currently trying to simplify!). Not to mention the complexity for plugin authors / documentation / etc. (toml is not simple strings and so I assume someone will come knocking on the door for custom toml data types soon enough as well).

And lastly, the comments about what other projects are doing and "flake8 is the hold out" are not at all productive to conversation -- if you have something productive about why flake8 should do it beyond "because toml is cool and everyone else is doin it" then please add to the discussion. Otherwise you're at best just adding another email to the inbox of the 80+ participants

In GitLab by @ericvw on Nov 27, 2019, 10:43

I echo a similar sentiment that @sigmavirus24 and @asottile share.

Looking at this pragmatically, adding, or migrating fully towards, pyproject.toml for flake8's doesn't add any significant value nor address any problems/shortcomings of flake8 as it stands today. It's a different file to be considered in a different format to be parsed — that's about it. While deprecation and removal of exiting behavior is always an option, it should also be given with great care due to its backward-incompatible nature and impact on downstream users and organizations that are heavily relying on what exists today.

While PEP 518 does specify that the [tool] can be used for other non-build tools, it does not require that projects respect it. Even when looking at PEP 518's overview of the file formats considered, the other features aren't needed for the configuration of flake8 — real data types aren't necessary (one could argue for lists, but the format of specifying this in INI is fairly simple and well-constrained) and Unicode is a non-issue. I do acknowledge there are other features listed that I am not explicitly addressing here, but don't find the trade-offs of significant value for flake8s use case (e.g., human editable, tool editable, well defined, etc).

Looking at other tools and utilities which have configuration files, they typically have their own well-defined file name and format which they respect. It's worthwhile to take a step back and ask ourselves why many utilities we use today take this approach instead of a single or shared configuration file Personally, I much prefer to use a tool-specific configuration file (i.,e .flake8 over tox.ini and setup.cfg). The scope and responsibilities are unambiguous. It also offers a lot more flexibility because the tool can choose a file format that makes sense for the use cases of the tool, itself. From a workflow perspective, everything is well-contained when traversing VCS history and reviewing code changes. There is nothing objectively wrong with having a few more files to be concerned with.

If there is a strong object and pragmatic argument of what pyproject.toml provides or solves that is problematic with flake8 today, then there is a useful discussion to be had. Otherwise, anything else that is in the realm of the popularity argument, because a PEP mentions a potential space for it, other other tools support it (which I would strongly argue they shouldn't for similar reasons outlined above) doesn't add anything further in the discussion until the fundamental question of what specifically pyproject.toml address/solves in flake8 can be answered.

In GitLab by @danyeaw on Nov 27, 2019, 11:45

Thanks for the great library :heart:

As a user of flake8, I would like to be able to have all of my Python project settings in a single file. That is my preference, but I understand that others may not find value in that.

This wasn't a request to solve a problem in flake8, this is a request to support a Feature that some users of the library would find value in. The trade off of this Feature request, is that it would increase the maintenance overhead, but it would still be a very valuable Feature to support for those that have this use case. Whether the maintainers of the library find that to be an acceptable trade off, is of course up to you.

Maybe someone would be willing to signup to support this Feature now and in the future?

In GitLab by @sigmavirus24 on Nov 27, 2019, 12:37

Maybe someone would be willing to signup to support this Feature now and in the future?

I see this suggestion so often and never does anyone step up. And frankly, especially in this case, with the horrible legacy that is config discovery and parsing in Flake8, I blame no one for wanting to step up to maintain this.

I also appreciate the implicit "Things work so well today, how hard could this really be to add" because that means that at least the config user experience isn't as bad as the config handling is in the code itself. (I still think it's crap behaviour but whatever.)

In GitLab by @thnee on Nov 28, 2019, 13:28

If it's already established that flake8 has a horrible legacy in its config parsing, then it seems to me that logically speaking the right thing to do is drop the old standards like setup.cfg, .flake8, tox.ini and just start fresh with the PEP standardized pyproject.toml. I don't see any practical reasons to wait any longer?

To anyone who says that it provides no new technical value, I would just like to say, sure, you are technically correct. But there is value in standardizing things. There is definitely an unnecessary complexity and learning curve currently in the Python ecosystem, when it comes to project config files, and that is worth improving. And to be clear I have no affiliation with any of this, this is just my opinion as a Python user who has created plenty of projects.

The point is it doesn't really matter so much if the file format is INI or TOML or something else, as long as the overall situation is improved and continues to improve.

In GitLab by @asottile on Nov 28, 2019, 13:49

If you want this, I'd suggest lobbying for the following:

pip to change its behaviour so mere presence of the file does not change functionality
- this probably involves a PEP, or at least a discussion on the various pypa mailing lists
python to consider adding a standard library toml implementation
- neither toml (the configration language) nor the python implementations (most popular being toml, tomlkit, pytoml afaik) on pypi are even 1.0 so I don't see this happening any time soon

the first one is a hard blocker for me accepting this as it imposes technical limitations on users which are outside of the control of this project. For example, consider the frustration due to the exact opposite issue on black

In GitLab by @janw on Nov 28, 2019, 14:26

@thnee

it seems to me that logically speaking the right thing to do is drop the old standards like setup.cfg, .flake8, tox.ini and just start fresh with the PEP standardized pyproject.toml.

I completely agree; that’s exactly what I was alluding to in my earlier comment. A clean cut with the next major release; dropping a few things that are basically just hindering progress, and adding complexity for maintainers, contributors and users alike.

The complexity argument keeps coming up here, so IMHO it’s clearly time to simplify. Bringing people another step closer to removing half a dozen config files from their repos would only be one such simplification.

Having had a look at the config parsing code I can even see why the argument comes up, but it certainly isn’t an impossible thing to untangle. In looking around a bit and trying out a few things I managed to replace all the possible INI file detection, parsing, etc. with a rudimentary pyproject.toml loader in the matter of a few hours, and immediately new options for simplification opened up.

And I’d be happy to contribute MRs for this.

In GitLab by @sigmavirus24 on Nov 28, 2019, 14:37

We've done our best to not deprecate things across major releases except when unable to maintain. iNI isn't the problem. The plethora of locations a file might be and how to mash them together. pyproject.toml is only a simplification in that it is only ever project local.

In GitLab by @chadgh on Jan 16, 2020, 09:03

Here is the awesome-pyproject list. It would be helpful if and when flake8 supports pyproject.toml to notify the list maintainer or submitting a PR to update the list indicating that flake8 supports the file now. Just FYI. :)

In GitLab by @erikkemperman on Feb 27, 2020, 04:19

I appreciate that just having fewer files (and especially formats) in the project root and "everyone else is doing it" aren't great arguments in favour of, well, anything.

However, I still find myself wishing flake8 would support pyproject.toml for pretty much those very reasons. Judging from this thread I am not alone, although I certainly acknowledge that others clearly express preference for having separate config files for each tool. I guess this is true especially when the configurations get more complicated -- whereas simple projects, sticking to the tool defaults mostly, might prefer a single file.

But I don't think it has to be either/or -- it seems to me it should be feasible to support whatever the user prefers.

I'm not a huge fan of TOML actually, but am not going to litigate the issue (the PEP mentions their rationale, such as it is). It's indeed unfortunate that there isn't yet a parser for it in the standard library, I agree, but both toml and tomlkit seem pretty reliable from what I've seen. The spec itself is not formally at 1.0 either but has been stable for years and the maintainers say that 1.0 will be compatible with the current (already pretty old) release.

My understanding is that Pip has resolved its troubles around the existence of pyproject.toml (but that's just from the release notes, I haven't actually tried anything complicated.)

So anyway, wanting to be constructive with my feedback, I took some time playing around with !245 (squashed the commits for legibility, rebased on current master, fixed some minor issues to make all the tests pass). And I'd like to hereby commit to spending some more time with it if anyone is interested or would like to suggest improvements.

https://gitlab.com/erikkemperman/flake8/-/commits/245-redux

@jgirardet Of course this remains almost completely your work, and so I took care to retain your authorship of the commit... But I trust you'll free to object to this -- I could either reset the author to myself and instead acknowledge your effort in the commit message, or simply throw away the whole thing if you prefer.

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

My understanding is that Pip has resolved its troubles around the existence of pyproject.toml

it is still a problem, the presence of pyproject.toml (even empty, or, containing a flake8 configuration) causes pip to change how it builds packages:

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

from setuptools import setup
setup(name='foo')
$ pip install .
Processing /tmp/x
Building wheels for collected packages: foo
  Building wheel for foo (setup.py) ... done
  Created wheel for foo: filename=foo-0.0.0-py3-none-any.whl size=949 sha256=7e277a98c8457ba5d9ce077e71e70c4a1f305ef8c1b545d35e6a8641ce926bfa
  Stored in directory: /tmp/pip-ephem-wheel-cache-o1_tikl8/wheels/ee/b3/31/be28105f11219b62c2dcf0cb7310ac9d23b417a75b7d21d607
Successfully built foo
Installing collected packages: foo
  Attempting uninstall: foo
    Found existing installation: foo 0.0.0
    Uninstalling foo-0.0.0:
      Successfully uninstalled foo-0.0.0
Successfully installed foo-0.0.0

$ touch pyproject.toml
$ pip install .
Processing /tmp/x
  Installing build dependencies ... done
  Getting requirements to build wheel ... error
  ERROR: Command errored out with exit status 1:
   command: /tmp/x/venv/bin/python /tmp/x/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmp6tj_q2ss
       cwd: /tmp/pip-req-build-9luoahsb
  Complete output (18 lines):
  Traceback (most recent call last):
    File "/tmp/x/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 257, in <module>
      main()
    File "/tmp/x/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 240, in main
      json_out['return_val'] = hook(**hook_input['kwargs'])
    File "/tmp/x/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py", line 91, in get_requires_for_build_wheel
      return hook(config_settings)
    File "/tmp/pip-build-env-w90x3yzd/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 148, in get_requires_for_build_wheel
      config_settings, requirements=['wheel'])
    File "/tmp/pip-build-env-w90x3yzd/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 128, in _get_build_requires
      self.run_setup()
    File "/tmp/pip-build-env-w90x3yzd/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 250, in run_setup
      self).run_setup(setup_script=setup_script)
    File "/tmp/pip-build-env-w90x3yzd/overlay/lib/python3.6/site-packages/setuptools/build_meta.py", line 143, in run_setup
      exec(compile(code, __file__, 'exec'), locals())
    File "setup.py", line 1, in <module>
      import six  # problem?
  ModuleNotFoundError: No module named 'six'
  ----------------------------------------
ERROR: Command errored out with exit status 1: /tmp/x/venv/bin/python /tmp/x/venv/lib/python3.6/site-packages/pip/_vendor/pep517/_in_process.py get_requires_for_build_wheel /tmp/tmp6tj_q2ss Check the logs for full command output.

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 https://github.com/pypa/pip/issues/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!

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

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?

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

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.

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

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.

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.

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.

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.

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.

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

PyCQA / flake8

pyproject.toml (PEP 518) support #234