8000 [WIP] Migrate to pytest by ColCarroll · Pull Request #6729 · Theano/Theano · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[WIP] Migrate to pytest #6729

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

[WIP] Migrate to pytest #6729

wants to merge 4 commits into from

Conversation

ColCarroll
Copy link

This is to give us access to tools we are more used to using, as well as ones that are actively maintained. There remains a lot of low-hanging fruit for improving the use of pytest:

  • fixtures
  • remove yield tests
  • more parametrization

This remains a WIP because I need to update the CI scripts.

Somewhat surprisingly, running the test suite requires only ~11minutes on my machine. I imagine it might take longer if some of the skipped tests no longer got skipped.

Also, np.ceil, np.floor, and np.trunc no longer work with theano tensors.

@nouiz
Copy link
Member
nouiz commented Nov 8, 2019

I'm not sure I'll find the time to review this. Theano isn't maintained anymore. Why do you want to do that for a software not maintained?

@ColCarroll
Copy link
Author

You're right that this is a ton of changes for a project that is not actively developed. It may make more sense to do a hard fork here:

My goal is to get at least 2 more years of stability for PyMC3: I think we gain a lot through a few tasks that are mostly automated

  • Drop nose in favor of pytest (nose is long deprecated, pymc devs are more familiar with pytest, pytest has an active ecosystem of tools to help focus bug fixes and new tests)
  • Drop Python 2 support (2to3 makes this fairly easy, Python2 is no longer supported in a month, and it lowers the code footprint needed to maintain a library)
  • Bump requirements of major libraries and test against current Python/numpy/scipy stack (this involves tracking down warnings and using static linters to keep up to date with deprecations in those libraries)

Do you have an opinion on the idea of a fork? I of course love Theano and appreciate all your work, but it seems as though your goals are to keep a lightly maintained version of Theano for legacy users, while PyMC3 is perhaps more willing to sacrifice backwards compatibility (and current stability! we certainly lack your familiarity with the codebase) for some amount of iteration.

@nouiz
Copy link
Member
nouiz commented Nov 8, 2019 via email

@ColCarroll
Copy link
Author

Thanks for the thoughtful reply -- I think a lot of my response boils down to the subtle difference in aims: it sounds like you aim to keep Theano running as-is for users, and I am aiming to keep Theano as a robust platform for PyMC3 to run on top of.

It feels as though we are running into more issues - small and large - in PyMC3, and I am trying to figure out how I can hop in and start fixing those here, as well as to make it easier for other PyMC3 contributors to help.

Broadly the two large issues I am looking at right now (I know others have issues) are:

  • The test suite on CPU emits 5,736 warnings. Those are not caused by overly many actual deprecated practices, but targeting the same numpy that PyMC3 does would make this fix easier.
  • Some code paths in PyMC3 (particularly with Gaussian processes) occasionally break on certain operating systems, or throw compilation errors that are fixed by uninstalling theano and numpy, then reinstalling somehow. I need to get a better reproduction of this, figure out if it is conda or pip and what operating system, but less compatibility code and more familiar tooling will help in that.

At the same time, I am looking towards more deprecations and subtle errors popping up in the future, and I would love to be able to submit fixes for those.

I understand there are other (better) ways of fixing these problems (like me getting more familiar with the current tooling and codebase), but given the amount of time I can spend submitting fixes, this is the fastest path I can see.

Moving the tests to pytest was partly a way for me to get familiar with the test suite, and a way to remove a dependency that has been deprecated for ~5 years. You are totally right that we do not get any immediate features from the switch -- I'm running coverage.py and profiling with it, but I know there are equivalent nose plugins. This is another change that makes development more comfortable and efficient for me.

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
0