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.

@conda-forge-admin, please rerender

I am happy to make a new release (dftd4/dftd4#348). There won't be many changes in dftd4, so I think shorter release cycles are fine.

I am happy to make a new release (dftd4/dftd4#348). There won't be many changes in dftd4, so I think shorter release cycles are fine.

4.1.0 is released.

Thanks for the new tag, @marvinfriede and @awvwgk ! This PR will fail until conda-forge/dftd4-feedstock#32 , of course, but after that, I think it's ready for consideration. I've set it up to close the regro PRs for py314 and the new v4.1.0, but if you'd rather work from those official PRs and close this one instead, that's perfectly fine with me. The cbc.yaml file allowing py314 testing to pass is the only thing special about this PR, and I'm doing several feedstocks this way.

I've set it up to close the regro PRs for py314 and the new v4.1.0

I am a bit confused (I have not worked with conda much). Don't we need to merge the regro PR first, because the PR here requires 4.1.0? I don't want to break your idea of handling the migration @loriab.

I've set it up to close the regro PRs for py314 and the new v4.1.0

I am a bit confused (I have not worked with conda much). Don't we need to merge the regro PR first, because the PR here requires 4.1.0? I don't want to break your idea of handling the migration @loriab.

tl;dr merge conda-forge/dftd4-feedstock#32 please, then wait for me to update this PR, and I'll ping you when it's ready.

@marvinfriede , sure, d3 & d4 are slightly more complicated because library and python are separate feedstocks. The first thing to do is to merge the 4.1 regro PR at the library feedstock (conda-forge/dftd4-feedstock#32). After that's built, we can consider this feedstock. Ordinarily, I'd mildly favor working from the regro PRs. But since neither #41 nor #35 can work without the other, it's fine to work from this PR that combines them. One quirk of conda-forge is that you don't want to close a migration PR like #35 until you've accomplished its work elsewhere (like here) since merging or closing is the signal that the migration can move onwards to dftd4-python's dependents. If you want to go ahead with PR 32, I can update this (by rerendering or otherwise prompting CI), then let you know when it's ready for consideration. Thanks for all your reviewing, tagging, and processing :-)

@conda-forge-admin, please rerender

Thanks for the detailed explanation @loriab!

@conda-forge-admin, please rerender

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/conda-forge-webservices/actions/runs/23932316640. Examine the logs at this URL for more detail.}

@marvinfriede, I think this PR is ready to merge, unless @awvwgk wants a new release with d4 and d3 interfaces matching (dftd4/dftd4#357). I ran the build again to check against the most recent mctc-lib. Please let me know if you've any questions or want changes.