amatch
amatch copied to clipboard
flori
Join forces
I found this excellent gem! 💎
It seems like there are a few ruby gems for string matching:
- https://github.com/kiyoka/fuzzy-string-match
- https://github.com/flori/amatch
- https://github.com/GlobalNamesArchitecture/damerau-levenshtein
- https://github.com/tonytonyjan/jaro_winkler/
Would it make sense to join forces? In other words, have several maintainers of one project.
String distance is a great functionality, but the API can be pretty static over time. So what's important is mostly to have several maintainers that can help each other with CI upgrades and similar.
ping @kiyoka @flori @dimus @tonytonyjan
I've opened issues in all three repos quoted above, with the same message
To avoid spreading the discussion across four threads, let's keep it all in this one.
Interesting idea @sandstrom, can you describe your proposal in a bit more detail?
Basically choose one of the projects (this is the hard part), if that project is missing something important from any of the others, port those features over, so that the chosen project mostly has feature parity with the others, then deprecate the others and concentrate future work in one repo/project.
There would then be several maintainers in the chosen project (less work for each, only one CI flow to manage, etc).
Since string distances is a pretty narrow concept, these libraries are basically feature complete as is (they are great though!). So most of the work that goes into them is about supporting new versions of Ruby, etc. Better if that burden is shared, also less risk of an abandoned gem, where no one has access any longer.
The respective projects would still remain, but probably with a notice saying that future development will occur in the chosen project, and a link to it.
All of these projects are in active use, and are registered as gems, so they pretty much cannot dissappear or be abandoned completely. Saying that, having a tool that aggregates functionality of all them would be nice.
I guess there are two approaches:
- to create a gem that sits on top of the projects and creates an adaptor interface to them
- to take important parts from the mentioned gems, and write a new gem that combines their functionality, which should not be a problem with open-source projects (the only important thing in this case would be to assign the correct license that is compatible with licenses of all used projects)
I'd vote for 2 (and preferably under one of the existing gems, instead of creating a brand new one; just make it a major version bump for any breaking changes).
Good point on licenses, I didn't think about that.
Feel free to use the source code of jaro_winkler (It's MIT license) and please include credit comments on the top of copied files if you plan to make another gem.
@tonytonyjan Would you be willing to also stay on as a maintainer, on a possible joint project?
No, I am willing to be a little contributor but would probably have no time to be a maintainer.