You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
providing configuration of flake8 via pyproject.toml was already requested earlier in #234. Since than the python world has evolved a lot, so I'm asking to rethink this.
Why support pyproject.toml at all?
toml is a standardize format. There are parser out there, so it's trivial for third-party application/libraries to get access to the config if they needed.
My concrete use case is nitpick which allows to have the central place for any kind of configs project should have. While there is support for parsing and writing setup.cfg-like files this becomes quite cumbersome in case of multiline/comma separated values.
pip to change its behaviour so mere presence of the file does not change functionality
The point was about the fact that pip will build a package by default than in an isolated environment, which broke some packages. The only packages that won't build in that case, are those that have build-dependency. That's the exact use case for PEP-518. Packages that need dependencies during build time and haven't specify them in a pyproject.toml are broken and it should be fixed by the maintainer(s).
In the last years the most maintainers have learned about PEP-518 in my experience. It might be due to the raise of Poetry, where those packages will definitely fail to build.
python to consider adding a standard library toml implementation
PEP-680 was accepted recently. So there will be a build-in tomllib from python3.11 on. This will be based on tomli.
Until then I would suggest that pyproject.toml is supported by in extra wich installs this additional dependency. This is how isort introduced it once.
fin swimmer
The text was updated successfully, but these errors were encountered:
Hello,
providing configuration of
flake8
viapyproject.toml
was already requested earlier in #234. Since than the python world has evolved a lot, so I'm asking to rethink this.Why support
pyproject.toml
at all?toml
is a standardize format. There are parser out there, so it's trivial for third-party application/libraries to get access to the config if they needed.My concrete use case is nitpick which allows to have the central place for any kind of configs project should have. While there is support for parsing and writing
setup.cfg
-like files this becomes quite cumbersome in case of multiline/comma separated values.In #234 (comment) @asottile said what are blockers for a
pyproject.toml
support:The point was about the fact that
pip
will build a package by default than in an isolated environment, which broke some packages. The only packages that won't build in that case, are those that have build-dependency. That's the exact use case for PEP-518. Packages that need dependencies during build time and haven't specify them in apyproject.toml
are broken and it should be fixed by the maintainer(s).In the last years the most maintainers have learned about PEP-518 in my experience. It might be due to the raise of Poetry, where those packages will definitely fail to build.
PEP-680 was accepted recently. So there will be a build-in
tomllib
from python3.11 on. This will be based on tomli.Until then I would suggest that
pyproject.toml
is supported by inextra
wich installs this additional dependency. This is howisort
introduced it once.fin swimmer
The text was updated successfully, but these errors were encountered: