Created attachment 325558 [details] redis-2.6.1.ebuild 2.6.x added py3 support. Tried on py26 and py32. Attaching ebuild that uses tarball from github just to get tests. Also trying to be a good gentoo user, starting my own instance of redis for testing. 2.6.2 _is_ available, but not properly tagged (see upstream issue https://github.com/andymccurdy/redis-py/issues/285). I still chose this older version since we now have test coverage that can verify 3.x working.
Thanks, maybe we should also file a bug on including tests in their tarballs?
I'm getting test failures (with redis-2.4.10 installed): ====================================================================== ERROR: test_channel_subscribe (tests.pubsub.PubSubTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/tests/pubsub.py", line 20, in test_channel_subscribe self.pubsub.subscribe('foo'), File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/redis/client.py", line 1341, in subscribe return self.execute_command('SUBSCRIBE', *channels) File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/redis/client.py", line 1293, in execute_command connection.connect() File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/redis/connection.py", line 217, in connect raise ConnectionError(self._error_message(e)) ConnectionError: Error 111 connecting localhost:6379. Connection refused. ====================================================================== ERROR: test_pattern_subscribe (tests.pubsub.PubSubTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/tests/pubsub.py", line 65, in test_pattern_subscribe self.pubsub.psubscribe('f*'), File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/redis/client.py", line 1319, in psubscribe return self.execute_command('PSUBSCRIBE', *patterns) File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/redis/client.py", line 1293, in execute_command connection.connect() File "/var/tmp/portage/dev-python/redis-py-2.6.1/work/redis-2.6.1/redis/connection.py", line 217, in connect raise ConnectionError(self._error_message(e)) ConnectionError: Error 111 connecting localhost:6379. Connection refused. ---------------------------------------------------------------------- Ran 140 tests in 7.687s
Hey, working with the test suite at the moment. Will update the ebuild soon enough.
Created attachment 326032 [details] redis-py-2.7.0.ebuild Updated version. Now uses a redis running on sockets instead of tcp.
Created attachment 326036 [details] redis-py-2.7.1.ebuild 2.7.1 was just released and now distributes tests. Reverting to old SRC_URI with the exception of renaming the tarball. redis has a similar naming and we don't want clashes there.
Created attachment 326050 [details] redis-2.7.1.ebuild Updated version. Again. Nothing major: - use EPREFIX - remove redundant PYTHON_DEPEND (thanks to Arfrever for pointing this out)
Still doesn't seem to work correctly: >>> Source compiled. find: paths must precede expression: tests/encoding.py Usage: find [-H] [-L] [-P] [-Olevel] [-D help|tree|search|stat|rates|opt|exec] [path...] [expression] [16170] 09 Oct 11:07:06 # Warning: no config file specified, using the default config. In order to specify a config file use 'redis-server /path/to/redis.conf' [16170] 09 Oct 11:07:06 * Server started, Redis version 2.4.10 [16170] 09 Oct 11:07:06 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. [16170] 09 Oct 11:07:06 * The server is now ready to accept connections on port 6379 [16170] 09 Oct 11:07:07 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:12 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:17 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:22 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:27 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:32 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:37 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:42 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:47 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:52 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:07:57 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:02 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:07 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:12 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:17 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:22 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:27 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:32 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:37 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:42 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:47 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:52 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:08:57 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:02 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:07 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:12 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:17 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:22 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:27 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:32 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:37 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:42 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:47 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:52 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:09:57 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:10:02 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:10:07 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:10:12 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:10:17 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:10:22 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:10:27 - 0 clients connected (0 slaves), 790840 bytes in use [16170] 09 Oct 11:10:32 - 0 clients connected (0 slaves), 790840 bytes in use (With no end in sight or signs of progress...)
(In reply to comment #7) > Still doesn't seem to work correctly: > > <snip> > > (With no end in sight or signs of progress...) So, it seems that neither find nor redis executes correctly for you (as compared to me). Not at the office atm, so I don't have access to that machine; but I'll try on some other rigs to see if its my local settings or your local settings that is the anomaly.
Created attachment 326134 [details] redis-py-2.7.1.ebuild New day, new ebuild. Thanks for your patience.
Done, thanks for sticking with it!
