v3.0 Planning

[dgasmith]

We are planning a major version bump for the following reasons:

• Transition to be backend agnostic (NumPy is no longer the principle backend).
  • See Implement backend='auto' and make it the default #81 which has the (small) potential to break current implementations.

TODO Items:

• Refactoring in preparation for NEP18 (NumPy Dispatch Mechanisms #46) should be considered.
• Consider adding a Ricci calculus parser contract('A_ij B_jk A_kl', {"A": a, "B": b}).
• Run through the backends to check where we can refactor.
• Update docs and README to reflect that we are NumPy agnostic.
• Consider parsers that use metrics besides raw FLOPS (actually trying out several contraction paths for example).

Are there other items where we might need to do a few (small) compatibility breaks that would be good for future sustainability?

[jcmgray]

Another small thing might be to fully deprecate/remove the path kwarg.

[dgasmith]

I think a lot of the above involves somewhat wishlist items. Becoming backend agnostic is the primary change that requires a 3.0. I believe the only real TODO is to make a docs pass to reflect this change.

@fritzo Would you mind double checking that Pyro works with the current master? I will follow up with other projects before we make this change.

[fritzo]

@dgasmith thanks for the ping. Yes Pyro appears to work with opt_einsum master.

[dgasmith]

@fritzo Awesome! Thanks for checking.

[dgasmith]

We haven't talked about NEP18 much, but looking into current implementations there is effectively nothing for us to do beyond slowly removing the current backend technology as more packages pick up this standard. Realistically, this likely means no actions for six months to a year as this is hammered out.

Beyond that, I think a decision on #91 is the last thing we need to do here?

[dgasmith]

Since @Thenerdstation is looking for new features I will work on the 3.0 release this week. @jcmgray @fritzo any blockers here?

[fritzo]

@dgasmith I see no blockers from Pyro.

[chaserileyroberts]

We don't really have any feature requests other than the Cython implementation, which I'm happy to try to help build!

[dgasmith]

That would be fantastic on the Cython implementation! I will try to jot down some notes on your issue this weekend about possible pitfalls and enhancements.

[jcmgray]

No blockers from me. And cython versions of the path optimizers would be fantastic I think.

[dgasmith]

v3 release minted, if anyone would like to try out the code before I push out releases to PyPI/Conda let me know.

[dgasmith]

v3 on PyPI and now rolling out to conda-forge. Thank you everyone for many excellent features this release!