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

py.test --doctest-modules doesn't skip setup.py #502

Closed
pytestbot opened this issue Apr 12, 2014 · 9 comments
Closed

py.test --doctest-modules doesn't skip setup.py #502

pytestbot opened this issue Apr 12, 2014 · 9 comments
Labels
good first issue easy issue that is friendly to new contributor plugin: doctests related to the doctests builtin plugin status: help wanted developers would like help from experts on this topic type: enhancement new feature or API change, should be merged into features branch

Comments

@pytestbot
Copy link
Contributor

Originally reported by: BitBucket: offbyone, GitHub: offbyone


If I have the following path layout:

/setup.py
/package_name/
/package_name/__init__.py

I expect --doctest-modules not to read in setup.py. I can control it with conftest.py, but that seems a bit iffy. A better way might be to (IF the project is a setuptools package) take advantage of the setuptools project declaration to find the set of modules under test there.

In any case, setup.py should be skipped.


@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


I guess we cannot just skip any basename setup.py because it might be something valid in pkgname/sub/setup.py e.g. But ignoring the toplevel setup.py seems fine, just a question through what means. Hardcoding in pytest source seems not optimal.

@pytestbot
Copy link
Contributor Author

Original comment by BitBucket: offbyone, GitHub: offbyone:


No argument there. There are some useful heuristics that might work, though; you can look for a project root (if so inclined), or maybe take the perspective that any setup.py in the current directory that is not also a package (ie: that doesn't contain init.py) qualifies as a setup.py for the purposes of the plugin.

@pytestbot
Copy link
Contributor Author

Original comment by BitBucket: encukou, GitHub: encukou:


Special-casing the project root isn't a good solution IMO. A project can have sub-packages that are to be installed as separate wheels, but these also need need doctests.

Would it make sense to use wildcard ignores, e.g. **/setup.py ? Or something like --ignore-toplevel=setup.py that checks for nonexistence of a sibling __init__.py?

I suppose I can write a plugin for it, if it's not material for mainline pytest.

@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


UI wise i usually consider it best if things just work without the need to find and set some option. So what about ignoring "setup.py" files from doctests if it contains "distutils" or "setuptools" as a string? Wouldn't this work for almost every case we discussed so far? (It's a heuristic but only applicable to doctests and we can see if anyone complains and if so add an option i guess).

@pytestbot
Copy link
Contributor Author

Original comment by BitBucket: encukou, GitHub: encukou:


Sounds good, combined with the check for top-level module.

@pytestbot
Copy link
Contributor Author

Original comment by holger krekel (BitBucket: hpk42, GitHub: hpk42):


PR welcome.

@pytestbot
Copy link
Contributor Author

Original comment by BitBucket: encukou, GitHub: encukou:


OK, it's on my list. (A plugin is the easy part; figuring out pytest's code/tests/docs structure will take some time, as I have other, more pressing, things to do.)

@pytestbot pytestbot added the type: enhancement new feature or API change, should be merged into features branch label Jun 15, 2015
@pfctdayelise pfctdayelise added the plugin: doctests related to the doctests builtin plugin label Jul 25, 2015
@RonnyPfannschmidt RonnyPfannschmidt added status: help wanted developers would like help from experts on this topic good first issue easy issue that is friendly to new contributor labels Apr 20, 2016
@bilderbuchi
Copy link
Contributor

#2834 has been merged, so this can be closed, right?

@RonnyPfannschmidt
Copy link
Member

yup, thanks for the note

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue easy issue that is friendly to new contributor plugin: doctests related to the doctests builtin plugin status: help wanted developers would like help from experts on this topic type: enhancement new feature or API change, should be merged into features branch
Projects
None yet
Development

No branches or pull requests

6 participants