Is this project inactive?

[goller]

Are there any future updates planned for this project? For example, porting to python3?

[wumpus]

The docs say it runs under python 3, but the source is python 2, and I got so excited about using it that I ended up porting it to pure py3. From the looks of it we should be able to use py3c to support python 2.6+ and 3 in the same package. However, I hesitate to actually put it up on pypi without any tests. I have used travis-ci before, and libcmph-dev ought to be available on travis-ci's ubuntu-based CI servers.

@pombredanne previously asked about a pypi release, and might be interested in helping.

If the current committers have any comments that would be nice @jflatow @tuulos

[jflatow]

IIRC the C bindings support both 2.6+ and 3. Sadly I believe the only tests are here: https://github.com/discoproject/discodb/blob/master/python/discodb/query.py

[pombredanne]

This library is quite unique indeed!

Sadly @tuulos @pmundkur and team kind lost interest when Bitdeli was acquired. I guess @traildb is what @tuulos focuses on these days. It used to use discodb but no loner :|

With that said, I never started to use it seriously because of this lack of activity. I will be willing to chip in, but not alone, and we would need a lead "maintainer".

• @wumpus where is your py3 port?
• @goller do you still maintain your Python 3 branch at https://github.com/goller/discodb/tree/python3
• @bauman has been quite active lately too in his fork. 'sup?
• @ontholerian and @goller used to be somewhat active a few years back. 'sup on your side?
• @srobertson you used to use it quite a bit @trivio . 'sup?
• @graingert I think you cared for discodb at some point?
• @jflatow you are an owner too

[graingert]

Not sure how best I could help

[bauman]

@pombredanne

My contributions are somewhat limited by my unique needs.

I am a heavy user of this library. I know of a few other heavy users as well.

I moved the library out of python since I needed the standalone C lib. I tried my best to re-integrate the python lib. As far as the python community goes, I'm hamstrung by python 2.7 on Red Hat with backports of everything useful. I don't have much to contribute on the py3 front.

Have no experience with lua or erlang either.

Would be happy to develop or maintain C library features.

[wumpus]

My (unfinished) attempt is now at https://github.com/wumpus/discodb

I was unaware of @GOllier's work, thanks for pointing that out.

I'd be happy to (1) lead and/or (2) provide porting, new tests, Travis-CI config, hook up the existing tests to Travis, etc

There are some decisions to be made:

• Support both py2 and py3 from the same package?
• What should the py3 interface be? (bytes or strings for keys and values)
• Continue to have the erlang client in the same repo? I don't know erlang.

[travisbrady]

Just casting my vote in favor of this project continuing, particularly given some of the encouraging results here: http://engineering.indeedblog.com/blog/2018/02/indeed-mph/

Perhaps some of the ideas in Indeed's MPH lib could be implemented in discodb.

[bauman]

just pointing out that the results of this image

http://engineering.indeedblog.com/wp-content/uploads/2018/01/mph5.png

are heavily weighted by discodb's python wrapper due to (comparatively) slow python UTF-8 string encodes. If you write k/v pairs using disco's own c library ripped out of of the python wrapper, disco becomes extremely write-performant.

That's exactly what I've done in my fork and exactly how I use it.

They do have a good point about final filesize being bloated in discodb because we keep all the string keys on-hand where indeed-mph nukes them to obtain a smaller file size.

I believe it's a useful (and differentiating) feature to allow a user to dump k/v pairs back out of the binary blob and you can only do that if you keep the copy somewhere.