Remove `e3nn` version pin

[Andrew-S-Rosen]

This is a feature request to ultimately remove the version pin of e3nn==0.4.4 in setup.cfg to allow for more flexible versions (if possible).

[ilyes319]

I tested it, and we seem to support the latest e3nn version. This will not be an easy decision, as it could weaken code interoperability, especially given how poorly TorchScript behaves. In which context is this problematic for you?

[Andrew-S-Rosen]

In my personal opinion, interoperability should be dependent on the individual packages being used. So, if mace supports all versions of e3nn but Package B doesn't, then Package B should be the one with a specific restriction on e3nn. But I understand that reality is a bit messier than this.

For me, it is not a huge issue. I package several machine learning workflows in my code quacc, which includes but is not limited to MACE. I allow users to pip install quacc[ml] to install the ML dependencies, but because mace is pinned to a specific version of e3nn, and some other libraries require e3nn>0.4.4 (I unfortunately don't remember which), they couldn't be installed together even though they are potentially compatible.

Edit: It was @zulissimeta who originally reported this to me.

[corinwagen]

Agreed, this would be really nice. e3nn==0.4.4 is now almost three years old, and newer packages like fairchem require e3nn>=0.5.0.

[ilyes319]

It is unlikely we will support it in the short term because it breaks backward compatibility. You are welcome to install 0.5 or later, the package will still work.

[Andrew-S-Rosen]

Ah, that's unfortunate. I don't know that I agree with the philosophy here, but I can understand the motivation. In what way does it break backwards compatability? Do energies change with the newer version of e3nn? If so, shouldn't mace want to use this presumably more accurate model architecture? If it is incompatible, a major version bump with an appropriate CHANGELOG would hopefully address this.

It is not practical to install 0.5 or later from a package management standpoint. I can't put e3nn>=0.5 in pyproject.toml, for instance, because that would conflict with mace if it is also in there.

[gabor1]

Can someone explain to me the issue? Surely all packages should allow the broadest possible (tested) set of versions to maximise flexibility within the constraint of correctness

[gabor1]

This does not preclude defining a more restricted subset of packages for vanilla installs whose goal is to simplify the installation process and minimise package conflicts. But this goal should not be conflated with the goal of allowing flexibility of someone wants it

[ilyes319]

e3nn changed the phase convention of the CG making the code not backward compatible and bunch of tests failing. There are ways to solve this, but it will be in the next release.

[Andrew-S-Rosen]

Ah okay, thanks for the clarity! I had assumed based on your prior comment that everything was still passing. Of course, failing tests should be a clear sign not to change the version yet.

[ilyes319]

The plan is to release 0.3.7 when all the bugs are fixed and then bump the version to 0.4.0 and update e3nn version to the latest, updating the tests. I would say a 2 months timeline.

[corinwagen]

Thanks for the update; makes total sense!

[bkmi]

I'm curious if there is progress on this. I imagine it's a rather large change actually. All models would either have to be retrained, or the basis transformation would have to be applied regularly throughout the network.

Any thoughts?