conda-forge / openff-toolkit-feedstock

A conda-smithy repository for openff-toolkit.

BSD 3-Clause "New" or "Revised" License

0 stars 7 forks source link

Remove `zstandard` pin #87

Closed mattwthompson closed 4 months ago

mattwthompson commented 4 months ago

86

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

mattwthompson commented 4 months ago

@conda-forge-admin, please rerender

conda-forge-webservices[bot] commented 4 months ago

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

github-actions[bot] commented 4 months ago

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you, but it looks like there was nothing to do.

This message was generated by GitHub actions workflow run https://github.com/conda-forge/openff-toolkit-feedstock/actions/runs/10096316188.

j-wags commented 4 months ago

Should I expect to see PYTHON_ZSTANDARD_IMPORT_POLICY='cffi_fallback' somewhere?

mattwthompson commented 4 months ago

Nope, we don't build or test against OpenEye here

j-wags commented 4 months ago

Won't users with OE installed just get the error again then?

mattwthompson commented 4 months ago

Maybe, but they should use the CFFI fallback instead of us downpinning to a very old version of an upstream (that we don't use)

j-wags commented 4 months ago

Many of our partner companies run with the OE backend and it's very bad if they wake up one day to find their OpenFF workflows don't work any more (it wastes their time, erodes support for renewing, and makes them less inclined to install the latest versions).

I have three thoughts on how to proceed, but could use more info:

Is OE clearly violating a packaging standard by bundling zstandard/would we have leverage to ask them to change their packages?
Can we or MolSSI incorporate an internal fix to activate the CFFI workaround without causing broader harm?
If neither of the above works, we'll need to document the workaround well and yell it from the mountaintops to soften the blow on our partner companies.

mattwthompson commented 4 months ago

I have no visibility into OpenEye's build process, but the environment they used in their most recent release is unchanged from several months ago and quite out of date for no obvious reason and aware of this issue we reported. OpenEye Support told us on 5/2/24 that "Since there is a workaround, it is unlikely this will be fixed for the next toolkit release" so I have no idea if they intend to fix this or when

There's no a solution without violating best practices - setting users' environment variables, importing packages they don't need, etc.