Own versions of python-bitshares and python-graphenelib

[bitphage]

We're experiencing large delays of merging required changes into upstream python-bitshares. Example: bitshares/python-bitshares#223 is blocking our #531.

Solution is to use own forks of python-bitshares and python-graphenelib.

Possible workfow:

• If we need a new feature, implement it into own versions first
• Do a PR into upstream, so all new features will be merged later as they are polished and stable
• Try to avoid incompatible changes
• Periodically merge upstream changes into our forks

[MarkoPaasila]

This seems like a good temporary solution, especially if @xeroc is ok with it

[thehapax]

I totally agree. If xeroc is ok it, I'd say @bitfag lets go with your suggestion so progress will not be slowed down.

[bitphage]

@joelvai how do you think best to use own version? Do you think we need to publish pypi packages like python-bitshares-dexbot, or just use git install in requirements, like git+https://github.com/foo/bar.git#egg=spam ?

Also I think it's good idea to put forked version Codaone github organization, someone with required permission need to do this.

[xeroc]

It is important that the approach works for you! If it serves that, go for it!

The only recommendation I would make is that you reuse what's already there and fits your requirements. Not re-implement the wheel. So, you may want to reuse alot of the stuff in bitsharesbase module.

[PermieBTS]

Great, thanks Xeroc

[bitphage]

I actually meant to use own versions to not wait for stuff being merged. So we can use new features right now, and PR them into upstream as things stabilizes.

[MarkoPaasila]

To me it seems like a better idea to pull source from git instead of making a pypi package.

[xeroc]

I actually meant to use own versions to not wait for stuff being merged. So we can use new features right now, and PR them into upstream as things stabilizes.

To be honest, I am looking for assistance in maintaining pybitshares for quite some time. Please ping me on telegram so we can discuss how best to work out the high delays (sorry for that) in merge requests. A new (and competent one like @bitfag) maintainer on the repo would be really really appreciated.

[bitphage]

@joelvai how do you think what is the best workflow with own forks? Do we need dexbot requirements.txt always point to master of pybitshares/pygraphene? Or our devel branch should point to develop branch of pybitshares/pygraphene? So we'll have the same merging approach develop -> master for pybitshares/pygraphene?

[xeroc]

If you do it like this, you may run into trouble as you forgot to remove the bitshares pypi package (one line above the added lines)!!

[bitphage]

Yes sure, just a mistake, already fixed.

[bitphage]

I thought about version pinning and I came into conclusion we need to pin to the commits or tags, like this:

git+https://github.com/Codaone/python-bitshares.git@78ff9808ea53f198d5fd975bf9f471621b2b5ad7#egg=bitshares
git+https://github.com/Codaone/[email protected]#egg=bitshares

So updating master/develop will not break any previous dexbot versions, and also it will ease testing of updated libraries on dexbot devel.

[xeroc]

You may want to do the pinning like this:

bitshares @ git+https://github.com/Codaone/python-bitshares.git@78ff9808ea53f198d5fd975bf9f471621b2b5ad7#egg=bitshares

See PIP508 example