Couple question regarding packaging of docker-py: * why does docker-py require docker? (I can connect to docker daemon over wire, it doesn't need to run on the same machine) * why does docker-py buildrequire docker? (there is no test-suite) * this one is probably consequence of first question: why's docker-py `ExclusiveArch: x86_64`? It doesn't have any arch specific code, it's just a wrapper on top REST calls.
(In reply to Tomas Tomecek from comment #0) > Couple question regarding packaging of docker-py: > > * why does docker-py require docker? (I can connect to docker daemon over > wire, it doesn't need to run on the same machine) > > * why does docker-py buildrequire docker? (there is no test-suite) The upstream releases on github (https://github.com/docker/docker-py/releases/) include tests. Might be a good idea to get the sources from there instead of pypi. > * this one is probably consequence of first question: why's docker-py > `ExclusiveArch: x86_64`? It doesn't have any arch specific code, it's just a > wrapper on top REST calls.
(In reply to Roman Mohr from comment #1) > (In reply to Tomas Tomecek from comment #0) > > * why does docker-py buildrequire docker? (there is no test-suite) > > The upstream releases on github > (https://github.com/docker/docker-py/releases/) include tests. Might be a > good idea to get the sources from there instead of pypi. You are right! I've never noticed the upstream test-suite. As I'm looking at it, it doesn't require running docker since all the api calls are mocked.
(In reply to Tomas Tomecek from comment #2) > (In reply to Roman Mohr from comment #1) > > (In reply to Tomas Tomecek from comment #0) > > > * why does docker-py buildrequire docker? (there is no test-suite) > > > > The upstream releases on github > > (https://github.com/docker/docker-py/releases/) include tests. Might be a > > good idea to get the sources from there instead of pypi. > > You are right! I've never noticed the upstream test-suite. As I'm looking at > it, it doesn't require running docker since all the api calls are mocked. I'm removing docker from BR (in addition to removing from R) as anyway running tests would involve invoking docker which needs sudo which isn't possible in mock. I'm adding 'make test' to %check and it'll run only if a /run/docker.sock is found. So people who need to use it can arrange for docker outside of python-docker-py installation.
(In reply to Lokesh Mandvekar from comment #3) > (In reply to Tomas Tomecek from comment #2) > > (In reply to Roman Mohr from comment #1) > > > (In reply to Tomas Tomecek from comment #0) > > > > * why does docker-py buildrequire docker? (there is no test-suite) > > > > > > The upstream releases on github > > > (https://github.com/docker/docker-py/releases/) include tests. Might be a > > > good idea to get the sources from there instead of pypi. > > > > You are right! I've never noticed the upstream test-suite. As I'm looking at > > it, it doesn't require running docker since all the api calls are mocked. > > I'm removing docker from BR (in addition to removing from R) as anyway > running tests would involve invoking docker which needs sudo which isn't > possible in mock. I'm adding 'make test' to %check and it'll run only if a > /run/docker.sock is found. So people who need to use it can arrange for > docker outside of python-docker-py installation. The Makefile always tries to build the package in a docker container (which is the reason why you are seeing the error). Jou could just run > py.test tests/test.py > py.test tests/utils_test.py As Tomas said, the whole docker server is mocked for the unit tests.
(In reply to Roman Mohr from comment #4) > > py.test tests/test.py > > py.test tests/utils_test.py > > As Tomas said, the whole docker server is mocked for the unit tests. You are right Roman. But no need to pull in py.test. This should work just fine: PYTHONPATH="${PWD}" %{__python} tests/test.py PYTHONPATH="${PWD}" %{__python} tests/utils_test.py %if 0%{?with_python3} pushd %{py3dir} PYTHONPATH="${PWD}" %{__python3} tests/test.py PYTHONPATH="${PWD}" %{__python3} tests/utils_test.py popd %endif # with_python3 In fact, I'm attaching patch for running the test suite.
Created attachment 995511 [details] patch for running mock test suite there is an inner patch for docker-py to remove "requests < 2.5.0" requirement
(In reply to Tomas Tomecek from comment #5) > (In reply to Roman Mohr from comment #4) > > > py.test tests/test.py > > > py.test tests/utils_test.py > > > > As Tomas said, the whole docker server is mocked for the unit tests. > > You are right Roman. But no need to pull in py.test. This should work just > fine: You are right Tomas. I never noticed the toplevel script environment. > PYTHONPATH="${PWD}" %{__python} tests/test.py > PYTHONPATH="${PWD}" %{__python} tests/utils_test.py > > %if 0%{?with_python3} > pushd %{py3dir} > PYTHONPATH="${PWD}" %{__python3} tests/test.py > PYTHONPATH="${PWD}" %{__python3} tests/utils_test.py > popd > %endif # with_python3 > > > In fact, I'm attaching patch for running the test suite.
(In reply to Tomas Tomecek from comment #6) > Created attachment 995511 [details] > patch for running mock test suite > > there is an inner patch for docker-py to remove "requests < 2.5.0" > requirement Does anyone know why upstream has the requests < 2.5.0 limitation? I ran a fedpkg mockbuild and the pyhon3 test run showed a few warnings regarding not closed files and sockets: > >/usr/lib64/python3.4/stringprep.py:220: ResourceWarning: unclosed file > <_io.FileIO name=11 mode='rb+'> > c22_specials = set([1757, 1807, 6158, 8204, 8205, 8232, 8233, 65279] + > list(range(8288,8292)) + list(range(8298,8304)) + list(range(65529,65533)) + > list(range(119155,119163))) > /usr/lib64/python3.4/unittest/case.py:615: ResourceWarning: unclosed > <socket.socket fd=6, family=AddressFamily.AF_UNIX, > type=SocketType.SOCK_STREAM, proto=0, raddr=/tmp/tmpnm0bcm8b/test_sock.sock> > testMethod() Most likely just not properly cleaned up tests. I will check in the evening if it is worth an upstream issue. Otherwise: LGTM
(In reply to Roman Mohr from comment #8) > (In reply to Tomas Tomecek from comment #6) > > Created attachment 995511 [details] > > patch for running mock test suite > > > > there is an inner patch for docker-py to remove "requests < 2.5.0" > > requirement > > Does anyone know why upstream has the requests < 2.5.0 limitation? > I ran a fedpkg mockbuild and the pyhon3 test run showed a few warnings > regarding not closed files and sockets: I've also tried it and test suite passed. Here's me asking about the issue [1] > > > >/usr/lib64/python3.4/stringprep.py:220: ResourceWarning: unclosed file > > <_io.FileIO name=11 mode='rb+'> > > c22_specials = set([1757, 1807, 6158, 8204, 8205, 8232, 8233, 65279] + > > list(range(8288,8292)) + list(range(8298,8304)) + list(range(65529,65533)) + > > list(range(119155,119163))) > > /usr/lib64/python3.4/unittest/case.py:615: ResourceWarning: unclosed > > <socket.socket fd=6, family=AddressFamily.AF_UNIX, > > type=SocketType.SOCK_STREAM, proto=0, raddr=/tmp/tmpnm0bcm8b/test_sock.sock> > > testMethod() > > Most likely just not properly cleaned up tests. I will check in the evening > if it is worth an upstream issue. > > Otherwise: LGTM [1] https://github.com/docker/docker-py/commit/9e295d666aa831eb32665bb7e748e3eab0f06a0c
(In reply to Roman Mohr from comment #8) > (In reply to Tomas Tomecek from comment #6) > > Created attachment 995511 [details] > > patch for running mock test suite > > > > there is an inner patch for docker-py to remove "requests < 2.5.0" > > requirement > > Does anyone know why upstream has the requests < 2.5.0 limitation? > I ran a fedpkg mockbuild and the pyhon3 test run showed a few warnings > regarding not closed files and sockets: > > > > >/usr/lib64/python3.4/stringprep.py:220: ResourceWarning: unclosed file > > <_io.FileIO name=11 mode='rb+'> > > c22_specials = set([1757, 1807, 6158, 8204, 8205, 8232, 8233, 65279] + > > list(range(8288,8292)) + list(range(8298,8304)) + list(range(65529,65533)) + > > list(range(119155,119163))) > > /usr/lib64/python3.4/unittest/case.py:615: ResourceWarning: unclosed > > <socket.socket fd=6, family=AddressFamily.AF_UNIX, > > type=SocketType.SOCK_STREAM, proto=0, raddr=/tmp/tmpnm0bcm8b/test_sock.sock> > > testMethod() > > Most likely just not properly cleaned up tests. I will check in the evening > if it is worth an upstream issue. Created a pull request here [2] to fix the warnings. They were indeed just caused by not properly cleand up tests. > Otherwise: LGTM [2] https://github.com/docker/docker-py/pull/511
(In reply to Tomas Tomecek from comment #9) > (In reply to Roman Mohr from comment #8) > > (In reply to Tomas Tomecek from comment #6) > > > Created attachment 995511 [details] > > > patch for running mock test suite > > > > > > there is an inner patch for docker-py to remove "requests < 2.5.0" > > > requirement > > > > Does anyone know why upstream has the requests < 2.5.0 limitation? > > I ran a fedpkg mockbuild and the pyhon3 test run showed a few warnings > > regarding not closed files and sockets: > > I've also tried it and test suite passed. Here's me asking about the issue > [1] Just to avoid a possible misunderstanding, they passed in my build too. I just wanted to mention the warnings. :) > > > > > >/usr/lib64/python3.4/stringprep.py:220: ResourceWarning: unclosed file > > > <_io.FileIO name=11 mode='rb+'> > > > c22_specials = set([1757, 1807, 6158, 8204, 8205, 8232, 8233, 65279] + > > > list(range(8288,8292)) + list(range(8298,8304)) + list(range(65529,65533)) + > > > list(range(119155,119163))) > > > /usr/lib64/python3.4/unittest/case.py:615: ResourceWarning: unclosed > > > <socket.socket fd=6, family=AddressFamily.AF_UNIX, > > > type=SocketType.SOCK_STREAM, proto=0, raddr=/tmp/tmpnm0bcm8b/test_sock.sock> > > > testMethod() > > > > Most likely just not properly cleaned up tests. I will check in the evening > > if it is worth an upstream issue. > > > > Otherwise: LGTM > > [1] > https://github.com/docker/docker-py/commit/ > 9e295d666aa831eb32665bb7e748e3eab0f06a0c
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
python-docker-py-1.1.0-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/python-docker-py-1.1.0-1.fc22
python-docker-py-0.7.1-2.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/python-docker-py-0.7.1-2.fc21
python-docker-py-0.7.1-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/python-docker-py-0.7.1-3.fc21
Package python-docker-py-0.7.1-3.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing python-docker-py-0.7.1-3.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-3844/python-docker-py-0.7.1-3.fc21 then log in and leave karma (feedback).
python-docker-py-1.1.0-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
python-docker-py-0.7.1-3.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.