Finish adapting the fork

[diamondman]

Modernize test suite, add CI support, make some design decisions...

@andre-merzky

[diamondman]

Something I was thinking about is how long we need to support python2. Python2's support has already passed the original sunset date, and several aspects of the codebase could be cleaned up if only Python3 was supported. I would like input from some users of the original bitarray library to know if they are using python 2.x still. https://python3statement.github.io/

[diamondman]

Uploading this fork to pip will cause a few problems.

• The existing package is not controlled by me so we will have to use a new name (bitarray1?).
• If the library name remains bitarray, it will be impossible to install along side the original bitarray library.
  • Changing the library name to bitarray1 would change the import path and require code changes to use the new fork (likely acceptable).
• Changing the library name prevents pull requests from the original bitarray from being easily mergable.
  • Either merge backlog of pull requests before changing the library name, or have a manual step of renaming the PR files before merging them.

[andre-merzky]

• I for one actually need python2 supported :/ Many of the machines we run on do not have python3 easily available (admins are very conservative in our context)
• I think it is acceptable to keep the module name, even with a changed pypi name. This makes for a proper forge which can easily be merged back, eventually. But either option works at the end.

[diamondman]

Maybe if we give the admins another decade they will get python 3 in your systems :). Shame, removing 2 would have cleaned up so much stuff and allowed some really cool new API changes in the future. At the very least we can keep python2 support until all cool patches are merged and then revisit.

My concern with the module name is that bitarray is distributed as a debian package python-bitarray, and I actually use that one for a debian package I maintain. I guess that as long as compatibility is not broken with the old version, overwriting the debian version with a newer version from pip would not break anything.

[andre-merzky]

Yeah, decade sounds about right :P I understand why that is a shame though (sigh) Ack on the revisit.

I see your concern on the debian package end -- I am not sure there is a good and quick solution, really, unless @ilanschnell replies at some point and either merges on the original repo, or cooperates on the pypi end. The other clean solution is to phase out bitarray in favor over bitarray1 over time, I guess...

[diamondman]

Exactly (on the debian stuff). We should first wait a bit to see how things go. Maybe @ilanschnell is happy with the library fulfilling his needs and no one messing with it. If that is the case and we know it, then we can fork everything with no need to be able to merge with the original project.

[ilanschnell]

I'm sorry for not being more responsive on PRs of my bitarray project, mostly because of a lack of time and other interests. Mostly, however, I am quite happy with the state of bitarray as it is, and while I'm still interested to fix bugs, and support newer Python versions (Python 3.6 is coming out in December), I consider the project feature complete. I don't want to stop development of new features, so forking the project is a solution which I welcome very much.

[diamondman]

@ilanschnell Thanks for taking the time to let us know the state of bitarray, as well as to give us your blessing. When we get more features together, I will make a PR to your project, and see if you are interested in pulling in the new work. Your code quality is really high, so we will have to maintain the same level of effort. We all really appreciate the great library you already produced, and I hope we can make it even better