Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding psi4 and dkh #22328

Merged
merged 88 commits into from
Apr 26, 2023
Merged

Adding psi4 and dkh #22328

merged 88 commits into from
Apr 26, 2023

Conversation

loriab
Copy link
Contributor

@loriab loriab commented Mar 18, 2023

Psi4 is a quantum chemistry package in Python and C++ with pybind11 bindings. It's been conda-packaged for a long time on its own channel (https://anaconda.org/psi4/psi4; recipe https://github.com/psi4/psi4meta/tree/master/conda-recipes/psi4-multiout), so this is finally a port to conda-forge, now that all required dependencies are available. The whole optional dependency ecosystem isn't ported yet, but I'm testing one of every language (C/Py: pylibefp; Fortran: dkh (alongside)), so I think this recipe is stable and ready for review.

The primary concern I anticipate is that this isn't packaging an upstream release, only an upstream branch. This is because the psi4 conda package and developer build instructions have always been based on -c defaults -c psi4, but there's one big and accumulating little changes to prepare for c-f deps, and I'd like to preserve the usability of the existing instructions until the whole software stack is ready on c-f. So if this recipe is merged, I expect that the first release from a c-f feedstock will have an ugly version (e.g., 1.8a2). I'd be glad to have it on a dev branch and psi4_dev channel if that can be done at feedstock-creation-time. A c-f compatible psi4 v1.8 release is due for late April/early May.

Checklist

  • Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
  • License file is packaged (see here for an example).
  • Source is from official source. (See notes above)
  • Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
  • If static libraries are linked in, the license of the static library is packaged. (No static libs)
  • Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
  • Build number is 0.
  • A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
  • GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
  • When in trouble, please check our knowledge base documentation before pinging a team.

@conda-forge-webservices
Copy link

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/dkh) and found some lint.

Here's what I've got...

For recipes/dkh:

  • There are 1 too many lines. There should be one empty line at the end of the file.

@conda-forge-webservices
Copy link

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 (recipes/dkh) and found it was in an excellent condition.

@conda-forge-webservices
Copy link

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/psi4) and found some lint.

Here's what I've got...

For recipes/psi4:

  • Failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint . from the recipe directory.

@conda-forge-webservices
Copy link

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 (recipes/psi4) and found it was in an excellent condition.

@loriab
Copy link
Contributor Author

loriab commented Mar 28, 2023

@conda-forge/help-c-cpp, ready for review!

@fevangelista
Copy link

fevangelista commented Apr 4, 2023

I am happy to help maintain this recipe.

@loriab loriab mentioned this pull request Apr 6, 2023
13 tasks
recipes/psi4/conda_build_config.yaml Show resolved Hide resolved
recipes/psi4/conda_build_config.yaml Outdated Show resolved Hide resolved
recipes/psi4/meta.yaml Outdated Show resolved Hide resolved
recipes/psi4/meta.yaml Outdated Show resolved Hide resolved
Comment on lines 111 to 113
- {{ pin_compatible('optking', upper_bound='0.5') }}
- {{ pin_compatible('qcelemental', upper_bound='0.50') }}
- {{ pin_compatible('qcengine', upper_bound='0.50') }}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are static linking / overdepending warnings in the logs for these libraries. Can you explain why they are needed at both runtime and build time if they aren't dynamically linked?

https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=690074&view=logs&j=6f142865-96c3-535c-b7ea-873d86b887bd&t=22b0682d-ab9e-55d7-9c79-49f3c3ba4823&l=13902

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These three are pure-python packages with no run_exports. Their important role is in requirements/run, and the upper bound is because there's some API-breaking changes planned in the next year, and I wanted to isolate the built packages from those. Because these three are required dependencies, if they're not present at cmake configure-time, psi4 will download and vendor them, so their presence in requirements/host avoids that.

Copy link
Member

@carterbox carterbox Apr 18, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're going to run into unresolvable dependencies in the future if you do it this way because eventually the host environment will move to optking =0.6.0 and then the run environment pinning expression will become optking >=0.6.0,<=0.5?

I think you want something like this:

host:
  - optking <0.6
run:
  - {{ pin_compatible('optking', max_pin='x.x') }}

Such that opking is always <0.6 and the same minor version in the host and run environments.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the analysis. Agreed that the original setup will take a little management of host v run to avoid the situation you describe. optking is fairly new (Dec 2022) and has a much faster release cycle (whenever) than psi4 (twice yearly), so I wanted to leave room for optking bugfixes that psi4 could access (so not pinning to x.x) and also put an upper bound so if optking finds it needs to do a breaking change, this version of psi can be insulated. It's some management, but I'm pretty sure an incompatibility will show up at build-time for me, not at solve-time for user, so I'm ok with it if you are.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved the upper bound for optking out to v0.15, so all three have 12+ versions of space before hitting the limit.

Copy link
Member

@carterbox carterbox Apr 26, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I meant this comment to apply to all three of optking, qcelemental, and qcengine. Manually specifying upper_bound is just a very unusual use of these pinning expressions.

I wanted to leave room for optking bugfixes that psi4 could access (so not pinning to x.x)

Pinning to x.x does allow for bugfixes? For example:

host:
  - optking 0.5.2
run:
  - {{ pin_compatible('optking', max_pin='x.x') }}
  # This template would be replaced with optking >=0.5.2,<0.6.0

Are the bugfixes for optking not shipped via increment of the patch (major.minor.patch) version number? For projects using SEMVER, breaking changes should never happen at the patch level.

EDIT: Hmmm... I linked the semver documentation, but it seems that according to the spec with major version 0, anything breaking can happen at any time. I typically still never break anything when bumping the patch version.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To allow for the widest compatability (accept bugfixes) whilst protecting against API breaks, you should use max_pin='x.x' for a package whose major version is zero. You can always rebuilt psi4 when new versions of these packages become available.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I should have said "room for bugfixes and development". optking is new-ish and likely to be fast moving, so I was just being cautious and leaving room for an API breaking change less momentous than 1.0. I can release the constraint if you like.

The qcelemental and qcengine are in a stack with qcfractal (presently at v0.15.8 on c-f). But the last has an imminent API breaking change at 0.50 (currently in development off-c-f at https://anaconda.org/qcarchive/qcfractal/files), and once that's ready, qcelemental and qcengine will have a similar scheduled API break that we'll align at v0.50 for consistency. So I think those two are important to keep.

fwiw, I've used the upper_bound pattern before, and it's worked cleanly for the users (all their complaints come to me :-) .

@@ -0,0 +1,71 @@
{% set name = "dkh" %}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DKH looks good in both recipe and logs; good job!

loriab and others added 4 commits April 18, 2023 19:07
Co-authored-by: Daniel Ching <carterbox@users.noreply.github.com>
Co-authored-by: Daniel Ching <carterbox@users.noreply.github.com>
@loriab
Copy link
Contributor Author

loriab commented Apr 19, 2023

Thanks very much for the review and improvements, @carterbox. I think I've addressed the comments, and I went ahead and added a third-party-licences file here, too, for a few miscellaneous files. CI will be running for a couple hours, but a one-python-version build was clean.

@loriab
Copy link
Contributor Author

loriab commented Apr 25, 2023

Sorry to ping you @carterbox, but is there anything I can do to facilitate this PR? I wouldn't usually push, but I've got a release date for psi4 looming. Thanks for all your work reviewing these.

Copy link
Member

@carterbox carterbox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm adjusting your pinning templates to be more conservative, so I can merge this PR today. These pinnings will better protect against API breaks. Just rebuild the package whenever new versions of any these dependencies are released.

recipes/psi4/meta.yaml Outdated Show resolved Hide resolved
@loriab
Copy link
Contributor Author

loriab commented Apr 26, 2023

I'm adjusting your pinning templates to be more conservative, so I can merge this PR today. These pinnings will better protect against API breaks. Just rebuild the package whenever new versions of any these dependencies are released.

Sounds good, thanks for the analysis, caution, and approval. :-)

@carterbox carterbox merged commit b366f5d into conda-forge:main Apr 26, 2023
@loriab loriab deleted the loriab-psi4 branch April 26, 2023 03:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants