search

omry / omegaconf

Flexible Python configuration system. The last one you will ever need.
BSD 3-Clause "New" or "Revised" License
1.96k stars 108 forks source link

Incompatible with current versions of antlr4 #1000

Open chris-morgan opened 2 years ago

chris-morgan commented 2 years ago

This is basically a repeat of #798, which took it from 4.8 to 4.9, and I think it indicates a systemic problem that would be good to get resolved in some way. (But I’m not getting involved—I’d just like a piece of software that happens to use omegaconf to work, but am not hung up on it.)

Trouble is that omegaconf.grammar.gen is generated ahead of time with antlr4, but antlr4 4.8, 4.9, 4.10 and 4.11 are all mutually incompatible, so you must use the same version of the antlr4 Java code that generates it, and the antlr4 Python library at runtime.

Specifying antlr4-python3-runtime==4.9.* in requirements/base.txt is all very well, but that may not be satisfiable, either due to something else depending on another version, or due to Linux distributions wanting to use the version they ship. My situation is that the python-antlr4 package in Arch Linux (community repository, meaning “official”) is at 4.11.1, so the python-omegaconf AUR package (AUR implies “unofficial”) is broken. The patch I’ve just suggested there is to depend on the antlr4 package (which provides /usr/share/java/antlr-4.11.1-complete.jar and the sans-version-number /usr/share/java/antlr-complete.jar) at build time, and patch omegaconf’s build_helpers/build_helpers.py to use the system’s copy of the antlr jar rather than the vendored one of an incompatible version. It’s certainly fair enough to say to Arch, “if you’re going to insist on violating our version requirement, you can patch it up yourself”, but it’s not an ideal situation.

I’m not just going to say “upgrade to 4.11”, though, because that just keeps you on the treadmill and is sure to create issues for others even as it fixes issues for some, because the current situation is just not good. Might be nice to figure out some way of avoiding these problems and the continual maintenance burden implied.

And maybe in the interim more deliberately support unvendoring the jar? Maybe an environment variable, to skip having to patch build_helpers/build_helpers.py?

omry commented 2 years ago

Given that antlr is pretty stable now, maybe it's worth opening a discussion with the antlr team about being more lax about version compatibility for the Python runtime.

astrojuanlu commented 1 year ago

Also, under certain conditions, antlr4-python3-runtime==4.9.* is producing a scary deprecation warning coming from pip:

  DEPRECATION: antlr4-python3-runtime is being installed using the legacy 'setup.py install' method, because it does not have a 'pyproject.toml' and the 'wheel' package is not installed. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/8559

modern versions have precompiled wheels uploaded and use modern packaging standards.