Is this project inactive?

discoproject / discodb

An efficient, immutable, persistent mapping object

http://discodb.readthedocs.org/

BSD 3-Clause "New" or "Revised" License

98 stars 31 forks source link

Is this project inactive? #12

Closed goller closed 7 months ago

goller commented 8 years ago

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

wumpus commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Not sure how best I could help

bauman commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

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 commented 5 years ago

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.