Skip to content

fix requires handling when using setup.cfg#1108

Merged
benoit-pierre merged 1 commit intopypa:masterfrom
benoit-pierre:fix_requires_handling,_again
Aug 1, 2017
Merged

fix requires handling when using setup.cfg#1108
benoit-pierre merged 1 commit intopypa:masterfrom
benoit-pierre:fix_requires_handling,_again

Conversation

@benoit-pierre
Copy link
Copy Markdown
Member

Fix #1105.

@suutari-ai
Copy link
Copy Markdown

Any comments on this? I'd love to get this merged.

@jaraco
Copy link
Copy Markdown
Member

jaraco commented Aug 1, 2017

Wow, quite a bit of work went into the tests refactor. I can see why you went there - wanting to extract the commonality of all the tests.

I'm pretty sure pytest_generate_tests has been superseded by parametrized fixtures, but that can be transformed later if needed.

The main concern I have about the refactoring is what does it do for the output? Is it still possible, for example, to select just one test to run? Is it still clear which test is being performed?

I'm also slightly concerned about the xfail syntax, which I presume was an unexpected introduction late. It's concerning in part because it's part of its own language, so it's not possible, for example to provide more detail (i.e. @pytest.mark.xfail(reason="..."))... without expanding the DSL.

I do like that the code seems to be more consolidated with this change. It does still feel a little uneasy that _finalize_requires gets called twice, but if that's what needs to happen, that's probably better than what was being done before.

If you're comfortable with the change being stable and addressed any concerns above to your satisfaction, would you add a CHANGELOG entry and then cut a release (release docs are in the repo)?

@benoit-pierre
Copy link
Copy Markdown
Member Author

I'm pretty sure pytest_generate_tests has been superseded by parametrized fixtures, but that can be transformed later if needed.

This seemed to be the simplest way to parametrize those tests while still keeping the code in-class. But I agree it could become unwieldily if multiple methods are parametrized using the same mechanism. Would this be better?

The main concern I have about the refactoring is what does it do for the output? Is it still possible, for example, to select just one test to run? Is it still clear which test is being performed?

Yes, that where the ids parameter come into play:

> python -m pytest --collect-only -qk test_requires
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_marker]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_marker_in_setup_cfg]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra_in_setup_cfg]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra_and_marker]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra_and_marker_in_setup_cfg]

=========================== short test summary info ============================
SKIP [2] /home/bpierre/progs/src/setuptools/setuptools/tests/test_msvc.py:17: could not import 'distutils.msvc9compiler'
============================= 293 tests deselected =============================
2 skipped, 293 deselected in 0.65 seconds

> python -m pytest --collect-only -qk install_requires
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_marker]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_marker_in_setup_cfg]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra_in_setup_cfg]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra_and_marker]
setuptools/tests/test_egg_info.py::TestEggInfo::test_requires[install_requires_with_extra_and_marker_in_setup_cfg]

=========================== short test summary info ============================
SKIP [2] /home/bpierre/progs/src/setuptools/setuptools/tests/test_msvc.py:17: could not import 'distutils.msvc9compiler'
============================= 293 tests deselected =============================
2 skipped, 293 deselected in 0.64 seconds

I'm also slightly concerned about the xfail syntax, which I presume was an unexpected introduction late. It's concerning in part because it's part of its own language, so it's not possible, for example to provide more detail (i.e. @pytest.mark.xfail(reason="..."))... without expanding the DSL.

Yeah, I could not find a way to mark a test by name.

@benoit-pierre benoit-pierre force-pushed the fix_requires_handling,_again branch from 6b4525b to 096f328 Compare August 1, 2017 22:21
@benoit-pierre
Copy link
Copy Markdown
Member Author

OK, I went ahead with the switch to pytest.mark.parametrize as it does make the code a little bit simpler.

@benoit-pierre benoit-pierre merged commit 558ed85 into pypa:master Aug 1, 2017
@benoit-pierre benoit-pierre deleted the fix_requires_handling,_again branch August 1, 2017 22:27
@suutari-ai
Copy link
Copy Markdown

Just tested this fix in setuptools 36.2.7 and it seems to work: I can now generate a wheel for Prequ with correct environment markers (with out-of-the-box setuptools and wheel packages). Thanks a lot! 😄

suutari-ai pushed a commit to suutari/prequ that referenced this pull request Aug 2, 2017
If the wheel is generated with older setuptools it will have incorrect
requirements for Python 3, since some of the requirements use
environment markers and there was a problem with those in older versions
of the setuptools.

See pypa/setuptools#1081 and
pypa/setuptools#1108 for details.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants