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

Import & test fixes. #20

Merged
merged 4 commits into from
Mar 4, 2017
Merged

Import & test fixes. #20

merged 4 commits into from
Mar 4, 2017

Conversation

anntzer
Copy link
Owner

@anntzer anntzer commented Feb 22, 2017

  • Try importing sphinx.ext.napoleon first (if you have a recent Sphinx
    installed, there's no reason to have sphinxcontrib.napoleon installed
    too).
  • Try importing unittest.mock first in the test suite (same as above).
  • Make tests runnable as python test_defopt.py.
  • Ignore vim's .*.swp swap files.

@evanunderscore
Copy link
Collaborator

evanunderscore commented Feb 23, 2017

Thanks for the PR. Taking the points in order:

  • There's already been some discussion about using Sphinx's version of Napoleon on attempt to import handle napoleon from sphinx #16. Given that it has to be an install-time dependency, I think we might as well use it. I'm open to ways around the dependency if you have them.
  • My reasoning for using mock is similar - it's in tests_require, so you're going to get it either way.
  • At some point I may switch to using pytest which I think would prevent the tests from being run this way, but for now I have no problem with it.
  • Looks good.

@anntzer
Copy link
Owner Author

anntzer commented Feb 23, 2017

I think 1) is reasonable (well I don't have a better idea right now).
For 2), I would then suggest making the dependency on mock dependent of the version of python with an env marker. This is because test_requires will install dependencies with easy_install (of course, pip is not involved at all...) which e.g. will indiscriminately install from pre-releases (pypa/setuptools#855) leading to all kinds of not-so-fun issues.
For 3) I'd say, right now you have a setup_requires on nose, which I'd like to drop for the same reason as above. Your test suite doesn't even need nose as a test runner! I guess that part of the PR can also be reverted in favor of just indicating that python setup.py test will run the test suite (which is actually standard, even though rarely followed). I happen to like pytest (a lot), but I'm not convinced there's much value of adding a dependency when the whole test suite is already unittest-compatible.

@evanunderscore
Copy link
Collaborator

For 2: There's no need for mock to be a dependency except for in testing. Perhaps we could switch to having some requirements files instead of having everything in the setup file. I agree that the way setuptools handles these requirements is not ideal.

For 3: Yes, there's no real reason to use nose. The coverage bit can be done by coverage itself. If we were to transition to pytest it would be to take advantage of its features.

@anntzer
Copy link
Owner Author

anntzer commented Feb 28, 2017

I don't think you can have conditional requirements in requirements files, so I'd rather keep the conditional import in test_defopt.py (I don't mind having an "extraneous" dependency (sphinxcontrib-napoleon) installed for library usage, but I'd rather avoid an extraneous test dependency).

- Try importing `sphinx.ext.napoleon` first (if you have a recent Sphinx
installed, there's no reason to have `sphinxcontrib.napoleon` installed
too).
- Try importing `unittest.mock` first in the test suite (same as above).
- Make tests runnable as `python test_defopt.py`.
- Ignore vim's `.*.swp` swap files.
@anntzer
Copy link
Owner Author

anntzer commented Feb 28, 2017

Force pushed, removed conditional import of sphinx.

@anntzer
Copy link
Owner Author

anntzer commented Mar 1, 2017

I added a commit that wraps lines at 79 characters. I understand not being strict about pep8 but I really have trouble working with files with long lines.

@anntzer
Copy link
Owner Author

anntzer commented Mar 1, 2017

FWIW markers in test_requires are only supported since setuptools 20.5 (https://setuptools.readthedocs.io/en/latest/history.html#id179) so I'd rather just get rid of test_require (and setup_requires) completely.

edit: ... on the other hand even the extra_requires approach only worked since setuptools 18, so that's just 9 months worth of releases (18 to 20.4) that you'd gain for not using markers in test_requires :-) (https://hynek.me/articles/conditional-python-dependencies/)

This was referenced Mar 1, 2017
defopt.py Outdated
:param short: Dictionary mapping parameter names to letters to use as
alternative short flags.
:param short: Dictionary mapping parameter names, after conversion of
underscores to dashes, to letters, to use as alternative short flags.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch. I find this hard to parse with the commas - could you instead put the added bit in parentheses?

@evanunderscore
Copy link
Collaborator

The tests are failing because enum34 wasn't installed, which means the environment markers you used didn't work. I vaguely remember having trouble trying to do this previously, which may be why I ended up doing it the way I did. You'll either have to figure out how to fix it, or undo that part of the change.

For nosetests, it technically belongs in setup_requires while the Travis build is using python setup.py nosetests. In the short term you can remove the dependency entirely and install it separately in .travis.yml.

Basically, you want `{"foo-bar": "f"}`, not `{"foo_bar":
"f"}`.  (I would keep the current behavior, as it also allows
`{"no-foo-bar": "F"}`.)
@anntzer
Copy link
Owner Author

anntzer commented Mar 3, 2017

Took me a few attempts but I finally got it right, I think.

@evanunderscore
Copy link
Collaborator

evanunderscore commented Mar 4, 2017

I don't think you have the coverage bit right. You need source under [coverage:run] (not [coverage:paths]) and you need to manually run coverage report as a separate command.

@evanunderscore
Copy link
Collaborator

Also there's no reason to continue to depend on nose now.

@anntzer
Copy link
Owner Author

anntzer commented Mar 4, 2017

Done.

@evanunderscore evanunderscore merged commit d7f6535 into anntzer:master Mar 4, 2017
@evanunderscore
Copy link
Collaborator

Thanks!

@anntzer anntzer deleted the fixes branch March 22, 2017 17:29
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.

2 participants