-
Notifications
You must be signed in to change notification settings - Fork 5
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
Infrastructure (installating, testing, etc.) #2
Conversation
23d5024
to
e5f4dfe
Compare
797fe85
to
fc9cd23
Compare
Basic code structure has been copied from Nengo.
Only test current Numpy and oldest supported Numpy, but test across different Nengo versions.
The location of the examples is not easily discoverable by the user, so it does not hurt much if they are hidden in a zip/egg file. At a later point a script should be added to extract them (and documentation) to a user specified location. I fixed the examples to pass the test, but at a later point I have still to go through all of them and make sure they adhere to the new nengo_spa syntax and all the descriptions make sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This LGTM. I've created and reviewed stuff using .pylintrc
and .travis.yml
so I feel pretty confident in this assessment. I went through a tutorial about MANIFEST.in
to understand it, so I'm slightly confident about it's approval as well. The rest of the changes appear to be pretty trivial.
Motivation and context:
This adds the files required to install nengo_spa, run the tests with py.test and tox, adds configuration for Travis-CI, AppVeyor, and CodeCov, etc.
I adjusted the examples to not fail the tests, but at a later point I have to go through and update the explanations and coding style for nengo_spa.
Most of the code in this PR has been copied from Nengo.
In contrast to Nengo I moved the examples into the
nengo_spa
directory to be able to install them as package data. The install location is somewhat obscure anyways, so that I don't expect most users to discover it. So installing them as package data which might end up in a zip/egg files should not matter to them. I leave it to a separate PR (#7) to add a script to extract these to a user defined location. (This is what setuptools suggests.).Some tests needed some adjustments to the tolerances to make them robust to different seeds.
Interactions with other PRs:
none
How has this been tested?
Running tests on continuous integration platforms.
How long should this take to review?
Where should a reviewer start?
It might not be necessary to check the changes to the examples very carefully as those have to be overhauled in a separate PR anyways. The current changes are just the minimal changeset to make them pass the tests (i.e. not raise any exceptions).
Types of changes:
Checklist:
Still to do: