Drop pydantic v1 fallback

[susilehtola]

Summary

Closes #113

• The optking/v1/optparams.py module imports from pydantic.v1, whose compatibility shim is broken on Python 3.14 (raises RuntimeError: no validator found for <class 'pydantic.v1.fields.UndefinedType'> at module import time).
• Fedora's RPM build runs an import check on every submodule and fails on optking.v1.optparams, even though the runtime selector in optking/__init__.py never reaches it when pydantic 2 is installed.
• Since optking/v2/optparams.py is already a complete, working pydantic-v2 implementation, drop the v1 fallback entirely.

Changes

• Remove optking/v1/optparams.py.
• optking/__init__.py: drop the pydantic.__version__ < 2 branch; always from .v2 import optparams as op.
• optking/optwrapper.py: remove from pydantic.v1.error_wrappers import ValidationError as v1ValidationError and collapse the (ValidationError, v1ValidationError) tuples to plain ValidationError.
• setup.py: bump install_requires to pydantic>=2.

Test plan

• import optking succeeds under pydantic 2.12 / Python 3.14
• Importing each submodule individually succeeds (mirrors the Fedora import-check sweep)
• OptParams regex validation still rejects/accepts the same inputs covered by test_options.py::test_regex_validation
• CustomHelper round-trip (to_dict -> from_dict) works with a v2 QCSchema OptimizationInput

🤖 Generated with Claude Code

[loriab]

@susilehtola, my aim in letting optking keep taking in qcschema v1 and emitting v1 and likewise v2 was so that older codebases needing optking (like psi4 v1.10) could keep working with latest optking rather than retroactively needing an optking version constraint (possible but involved on conda; impossible in general).

@AlexHeide, you might try checking the python version and only for <314 importing the v1/optparams?

[AlexHeide]

@AlexHeide, you might try checking the python version and only for <314 importing the v1/optparams?

If I'm understanding things correctly. Adding a version check for python 3.14 won't affect the RPM build system.

Fedora's RPM build runs an import check on every submodule and fails on optking.v1.optparams, even though the runtime selector in optking/init.py never reaches it when pydantic 2 is installed.

Susi, would just adding an exception to the import check so that optking.v1 doesn't get import checked be acceptable/possible? I'm not super familiar with RPM packaging but it looks to me like there's an -e/--exclude flag for the pyproject_import_check macro.

I'm a little hesitant to drop pydantic v1 right now. I suppose we could rename v1/optparams.py and v2 to _v1/ and _v2/ and import them from optking/optparams.py. The macro's docs indicate they'd be excluded automatically then.

[loriab]

Fedora's RPM build runs an import check on every submodule and fails on optking.v1.optparams, even though the runtime selector in optking/init.py never reaches it when pydantic 2 is installed.

Oh, got it.

https://github.com/psi-rking/optking/blob/master/optking/v1/optparams.py#L14 will be ok for submodule import, so it's only the two classes that will be problematic. I don't like indenting most of the file, but you could possibly leave the top and bottom as-is and only define the two classes if <314. possibly have to assign them to OptParams = None etc. in >=314 case. In qcel we use a more complicated placholder system (https://github.com/MolSSI/QCElemental/blob/next2026/qcelemental/models/v1/__init__.py) but that's b/c users are expected to create those classes, where here you have full control.