[Discussion] Dockerised development flow#23
[Discussion] Dockerised development flow#23garry-jeromson wants to merge 3 commits intobrunns:masterfrom
Conversation
garry-jeromson
force-pushed
the
dockerize-dev-setup
branch
from
e808c67 to
d033e9e
Compare
garry-jeromson
changed the title
setup.py
Outdated
| logger.warning("README file not found or unreadable.") | ||
| long_description = "See https://github.com/brunns/mbtest/" | ||
|
|
||
| with open('requirements.txt') as f: |
There was a problem hiding this comment.
Is there some way we can do without this? This is how I used to do it, but there is at least one downstream service which needs setup.py to be self contained, IIRC.
There was a problem hiding this comment.
Might be that we just have to live with having two copies of the requirements list - not really a biggie.
There was a problem hiding this comment.
Actually, if tox.ini, setup.py and requirements.txt can live independently of each other, it may simplify supporting both non-Dockerised and Dockerised workflows - the Docker containers would rely on the requirements.txt files, and tox would keep on doing its thing. Do you see any potential issues there?
There was a problem hiding this comment.
I'd like something in the build ensuring the two are in sync. If we have that, I can live with the duplication.
There was a problem hiding this comment.
Or, better still, can we build requirements.txt from setup.py, make it a generated artifact?
There was a problem hiding this comment.
One potential option: https://github.com/jazzband/pip-tools#example-usage-for-pip-compile
There was a problem hiding this comment.
Travis is unhappy. I'm not sure why that's not showing up in the PR - I'll look into that.
garry-jeromson
force-pushed
the
dockerize-dev-setup
branch
5 times, most recently
from
4ba5129 to
ac7b232
Compare
|
I'd say we're cooking with gas on this now - all that's left to do is to bring the Docker Makefile to feature parity with the tox one, and update the docs. |
|
Can you add a travis target, so we can see if anything breaks the docker build? |
|
Is the |
Have changed it back and added an easy way to switch between the two from the command line.
I'm a Travis noob - not sure if what I added is in the right place. |
garry-jeromson
force-pushed
the
dockerize-dev-setup
branch
3 times, most recently
from
7c6e8a0 to
61b432b
Compare
| tox -e py38 -- pip list --outdated | ||
|
|
||
| .PHONY: use-docker | ||
| use-docker: ## Use Docker-based local development workflow |
There was a problem hiding this comment.
This leaves my git status dirty. I wonder if that's avoidable?
There was a problem hiding this comment.
An alternative would be to have both tox and Docker targets in the same Makefile, and switching which targets are executed based on a variable. That would still leave the variable as a potential dirty status candidate though, and the Makefile would be really long.
garry-jeromson
force-pushed
the
dockerize-dev-setup
branch
from
61b432b to
ce01f5d
Compare
This allows running `make precommit` and coming out the other side with a clean Git status.
garry-jeromson
force-pushed
the
dockerize-dev-setup
branch
from
ce01f5d to
765028c
Compare
Probably need to find a more robust way of installation.
|
How are we going with this? BTW, I came across https://github.com/kudulab/dojo which might be useful... |
|
Coming back to this after a loooong time with fresh eyes; I wonder if it's actually going to be useful to anyone. The tox-based workflow isn't really a hurdle at all if you know what you're doing, and the Docker stuff adds complexity - if it's not gonna be used by other folks, perhaps we should just can it? |
|
Perhaps. I won't be using it myself, put perhaps it'll be useful to some folks? |
brunns
force-pushed
the
master
branch
4 times, most recently
from
b570521 to
9db229f
Compare
brunns
force-pushed
the
master
branch
2 times, most recently
from
1d4ecbc to
09eedff
Compare
brunns
force-pushed
the
master
branch
3 times, most recently
from
4af0bc2 to
e860499
Compare
2 participants
This is far from complete, and is meant to serve as a starting point for discussion.
A Dockerized development setup has the advantage that all the developer needs to have installed is
makeand Docker - all the Python stuff is containerised, making it more accessible (and hopefully, because of that, more "developable"). This, however, is a departure from the current project setup based on tox.Tox and Docker are two difference approaches to the same problem (testing with multiple Python versions) - it doesn't really make sense to run tox commands within a Docker container, and it may be tricky to support both development approaches simultaneously.
This commit forms the basis of my suggested initial approach:
setup.py(assuming tox and setup.py can then reference it, to avoid maintaining duplicate lists of the same dependencies)