Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuration via pyproject.toml #664

Closed
nedbat opened this issue Jun 11, 2018 · 9 comments
Closed

Allow configuration via pyproject.toml #664

nedbat opened this issue Jun 11, 2018 · 9 comments
Labels
enhancement New feature or request

Comments

@nedbat
Copy link
Owner

nedbat commented Jun 11, 2018

Originally reported by pradyunsg (Bitbucket: pradyunsg, GitHub: pradyunsg)


As per PEP 518, tools can use tool.<pypi-name> namespace within the pyproject.toml file if they own <pypi-name> on PyPI.

Allowing configuration via the above mechanism would allow for users to have a single file in their root directory, for configuring this coverage (and other tools) for their project. Essentially, this would allow eliminating a .coveragerc file in the root of the project in favor of using pyproject.toml.


@nedbat
Copy link
Owner Author

nedbat commented Jun 11, 2018

This is a good idea. One twist: coverage.py has no required dependencies. It will need a toml parser to parse the pyproject.toml file. My inclination is to implement this so that if the toml module is available, then coverage will try to read the pyproject.toml file. Installing coverage won't install toml automatically, you'll have to do that yourself if you want to use pyproject.toml for configuration.

@nedbat nedbat added minor enhancement New feature or request labels Jun 23, 2018
@nedbat nedbat removed the 4.5 label Aug 17, 2018
@butla
Copy link

butla commented Feb 14, 2019

@nedbat What about vendoring the toml library along with coverage? Would you be ok with that approach? Some projects do that (I think Pipenv does that with Pip, although there are probably examples in less chaotic projects as well [that's not to say that Pipenv is bad] ), to stay independent of other dependencies, and act as a self-contained dependency.

@butla
Copy link

butla commented Feb 14, 2019

Or on the other hand... your solution seems more sensible :) Just have to document that.

@mhozza
Copy link

mhozza commented Jul 3, 2019

You can also list it as optional dependency.

@zsiciarz
Copy link

zsiciarz commented Jul 5, 2019

+1 for optional dependency, isort does that for example: pip install isort[pyproject].

hugovk added a commit to hugovk/awesome-python-packaging that referenced this issue Oct 23, 2019
@nedbat
Copy link
Owner Author

nedbat commented Nov 4, 2019

This is finished as of df744f8

@nedbat nedbat closed this as completed Nov 4, 2019
@adithyabsk
Copy link

Awesome, @nedbat thanks for helping move this along. Assume this will land in the next release?

@nedbat
Copy link
Owner Author

nedbat commented Nov 4, 2019

Yes, if by next release you mean 5.0.

@nedbat
Copy link
Owner Author

nedbat commented Nov 11, 2019

This is available in 5.0b1: https://pypi.org/project/coverage/5.0b1/

stdedos added a commit to stdedos/pytest-cov that referenced this issue Sep 16, 2022
nedbat/coveragepy#664 (+ later fixes)

Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
stdedos added a commit to stdedos/pytest-cov that referenced this issue Sep 29, 2022
nedbat/coveragepy#664 (+ later fixes)

Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
ionelmc pushed a commit to pytest-dev/pytest-cov that referenced this issue Oct 18, 2022
nedbat/coveragepy#664 (+ later fixes)

Signed-off-by: Stavros Ntentos <133706+stdedos@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants