Check that API package installs#34
Conversation
| @@ -0,0 +1,12 @@ | |||
| [tox] | |||
There was a problem hiding this comment.
Curious, given we will have other packages (e.g. opentelemetry-sdk) under this repo, do we want to have a single global tox, or a tox file per package?
There was a problem hiding this comment.
I don't know what best practises are here, but I'd imagine we will have quite some code/config duplication with multiple toxfiles 🤔 I think OpenCensus-python used nox, maybe that tool is better in this regard?
There was a problem hiding this comment.
From a conversation with @reyang: nox gives us a combined coverage report if we have branches that depend on python version, but tox made it easier to run tests in parallel on travis. We'll stick with tox and burn the coverage bridge when we come to it.
I don't know whether it'll be easier to have one or multiple tox files. It does make it easier now to have it under opentelemetry-api since there's no code yet to check in the SDK.
| [tox] | ||
| skipsdist = True | ||
| envlist = py37-lint, py37-mypy | ||
| envlist = py{34,35,36,37}-unit, py37-lint, py37-mypy |
There was a problem hiding this comment.
If there is going to be multiple tox files, is the idea to have a different build per package? I think we need to define what makes sense in the project structure to "build differently".
There was a problem hiding this comment.
Still TBD, I don't have an opinion on this.
|
|
||
| script: | ||
| - tox | ||
| - (cd opentelemetry-api; tox) |
There was a problem hiding this comment.
Just wondering, is this part of the WIP or are we only building what is inside the api package?
There was a problem hiding this comment.
We'll eventually build everything, for now only API has code to build.
…en-telemetry#34) * reorder compiler options * update target to ensure compilation does not alter generated code
4 participants
WIP for now to test travis builds, don't merge this!