Add Docker tools#943
Conversation
Codecov Report
@@ Coverage Diff @@
## master #943 +/- ##
=======================================
Coverage 92.85% 92.85%
=======================================
Files 12 12
Lines 2379 2379
Branches 413 413
=======================================
Hits 2209 2209
Misses 107 107
Partials 63 63Continue to review full report at Codecov.
|
gaborbernat
left a comment
gaborbernat
left a comment
There was a problem hiding this comment.
I'm not a big fan of this. First we should prefer using py37 instead py36. Furthermore who's going to test/maintain this is correct, we don't have any CI tests for such. Second docker seems a much heavier requirement to introduce instead of just Python that we have as of today.
|
Using 3.7 is fine -- I was going by the contribution guidelines, which ask to run:
As for who's going to test/maintain it, I could remove the pegged dependency from the Dockerfile to be simply As for heavy/light I'd argue that's a bit of a matter of opinion. This isn't meant to be an additional requirement for users, but another option for installation (or "anti-installation"). Some devs prefer to work entirely in containers (many of my coworkers, for example) for a variety of reasons, one of which is not having to worry about polluting their host environments with potentially incompatible installations across projects. At the end of the day, it's totally up to you. I can always post this image to my personal Dockerhub if it's not welcome here. |
- Add Dockerfile with Python 2.7+3.6 interpreters and tox installed - Add docker-compose configuration to run tests with '-e fix-lint,py27,py36'
|
I'm sort of agreeing we might want to do this; however in a fashion where we can enforce some CI rules. Until we setup docker hub I would be hesitant to accept anything. Furthermore, I would say we don't want to pass in anything under |
gaborbernat
left a comment
gaborbernat
left a comment
There was a problem hiding this comment.
I'm sort of agreeing we might want to do this; however in a fashion where we can enforce some CI rules. Until we setup docker hub I would be hesitant to accept anything. Furthermore, I would say we don't want to pass in anything under tox -e, we should just let the default envlist kick in.
|
I'll close this now, in favor of #1035. I feel we should first discuss how we want to provide and maintain this. |
|
Sorry I haven't had the time to give this the attn it deserves. I'll add my thoughts to the issue above. Thanks for all your work on |
2 participants
Run tests with
docker-compose run --rm tox.Consider publishing official Docker image that can be pulled with
docker pull tox. This would allow users to run tox tests without ever needing to install tox locally. Users can mount their projects to the/toxdirectory inside the image and run tests in a containerized environment (as is done indocker-compose.yml)Thanks for contributing a pull request!
If you are contributing for the first time or provide a trivial fix don't worry too
much about the checklist - we will help you get started.
Contribution checklist:
(also see CONTRIBUTING.rst for details)
in message body
<issue number>.<type>.rstfor example (588.bugfix.rst)<type>is must be one ofbugfix,feature,deprecation,breaking,doc,miscCONTRIBUTORS(preserving alphabetical order)