-
Notifications
You must be signed in to change notification settings - Fork 16.4k
[AIRFLOW-1057] fix class name that is changed at docker package version 2.0.0 #2204
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
Conversation
|
Thanks for the contribution. Please follow the commit guidelines. Also, is this backward compatible? |
|
I have now improved the import to cater for those people that use docker-py prior to 2.0.0. It will now first try to import APIClient, but if that fails it imports Client as APIClient. |
|
I've checked this pr it seems ok to me. Maybe changing the require to be able to install either the docker-py (v1.xx) or docker (v2.xx) would be a good add. |
|
I am not familiar with the docker-py package. The package on pypi has not been updated since November 2016 and the documentation of that package seems to point to the docker package documentation (https://docker-py.readthedocs.io/en/latest/) I have manually installed the docker package and did not rely on dependencies from setup.py. That's how I found out. Can someone shed a light on the difference between these two packages? |
|
They are basically the same package. Prior to version 2.x it was called docker-py, and since version 2 they switched to docker. |
|
Ok. I'll make the dependency such that it checks if either docker-py or docker is installed. Installing the docker dependency (in setup.py) will pull down the docker package. |
|
ok -- I know where to change the docker package dependency: line 125 of But I am not sure how to validate if docker-py may be installed and rely on that version. I am new to python packaging. |
|
I'm not sure if it's considered good practice, but you can import it in a try except and if it's present it won't throw. |
|
that is now the way I do it. the import tries to |
GaelMagnan
left a comment
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.
It looks good to me, just the test maybe have the same comportment that in the operator, to handle the case where the docker-py library is installed.
tests/operators/docker_operator.py
Outdated
| try: | ||
| from airflow.operators.docker_operator import DockerOperator | ||
| from docker.client import Client | ||
| from docker.client import APIClient |
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.
You don't test if docker-py is installed during the tests to fallback?
Codecov Report
@@ Coverage Diff @@
## master #2204 +/- ##
==========================================
+ Coverage 69.22% 69.24% +0.02%
==========================================
Files 145 145
Lines 11134 11138 +4
==========================================
+ Hits 7707 7712 +5
+ Misses 3427 3426 -1
Continue to review full report at Codecov.
|
|
updated the test so is does the same check on which docker package is installed. |
|
please squash your commits, make sure you follow the commit guidelines for the commit message and then we are good to go. |
|
I think this is now in line with the guidelines -- anything I missed? |
|
I think you are missing
so something like |
|
I think it already does have a subject line that is exactly that. Do you mean something else, @avigil-twist ? |
|
you changed the name of this pull request but not the name of the commit itself |
…on 2.0.0 adding conditional import to provide backward compatibility for package docker-py changed dependency for docker package; now docker rather than docker-py updated test cases to align to new docker class; also testing for old docker.py in test
|
got it, @avigil-twist and fixed that now |
|
This PR never got merged as far as I can tell, but the associated issue is marked as RESOLVED https://issues.apache.org/jira/browse/AIRFLOW-1057... is it actually RESOLVED? |
|
Well, @russellpierce, I must say I am not entirely sure either. I have been using my fork for most of the time. I'll check. |
|
Just had a quick look at the code (current master branch https://github.com/apache/incubator-airflow/blob/master/airflow/operators/docker_operator.py) but there we just import I think I put the issue to "resolved" to mean: there is a pull request that needs validation. Reopened the issue. |
| from docker import APIClient | ||
| except ImportError: | ||
| # prior to version 2.0.0 of the module docker, the API client was called Client | ||
| from docker import Client as APIClient |
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.
Given we now depend upon the more recent docker lib (and that is the right thing to do) I don't think there is any need to have this fallback behaviour -- we will always have at least docker 2.0 won't we?
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.
Sure. Maybe we should have that reflect in the setup.py as well? The master version still read "docker = ['docker-py>=1.6.0']" which now should be "docker = ['docker-py>=2.0.0']"
|
Has this stalled again or will it make it to 2.0? Also FYI this pr doesn't work against docker >= 3.0.0 due to breaking api changes in the docker client library: |
|
@brokenjacobs This first needs to be fixed; there are a lot of merge conflicts right now. |
|
This PR can be closed. It was fixed on #3407 |
Dear Airflow maintainers,
Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
JIRA
Description
This fixes an incorrect reference to a class in the docker package
Tests
Commits