-
Notifications
You must be signed in to change notification settings - Fork 15
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
[Discussion] Dockerised development flow #23
base: master
Are you sure you want to change the base?
Conversation
e808c67
to
d033e9e
Compare
setup.py
Outdated
@@ -18,6 +18,9 @@ | |||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, better still, can we build requirements.txt
from setup.py
, make it a generated artifact?
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.
One potential option: https://github.com/jazzband/pip-tools#example-usage-for-pip-compile
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.
Looks worth a try!
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.
Travis is unhappy. I'm not sure why that's not showing up in the PR - I'll look into that.
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. |
7c6e8a0
to
61b432b
Compare
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.
Seems to be working for me.
@@ -88,6 +88,11 @@ repl: ## Python REPL | |||
outdated: ## List outdated dependancies | |||
tox -e py38 -- pip list --outdated | |||
|
|||
.PHONY: use-docker | |||
use-docker: ## Use Docker-based local development workflow |
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 leaves my git status
dirty. I wonder if that's avoidable?
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.
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.
61b432b
to
ce01f5d
Compare
This allows running `make precommit` and coming out the other side with a clean Git status.
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? |
b570521
to
9db229f
Compare
1d4ecbc
to
09eedff
Compare
4af0bc2
to
e860499
Compare
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
make
and 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)