-
-
Notifications
You must be signed in to change notification settings - Fork 5k
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
Adding psi4 and dkh #22328
Conversation
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 ( Here's what I've got... For recipes/dkh:
|
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 ( |
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 ( Here's what I've got... For recipes/psi4:
|
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 ( |
@conda-forge/help-c-cpp, ready for review! |
I am happy to help maintain this recipe. |
recipes/psi4/meta.yaml
Outdated
- {{ pin_compatible('optking', upper_bound='0.5') }} | ||
- {{ pin_compatible('qcelemental', upper_bound='0.50') }} | ||
- {{ pin_compatible('qcengine', upper_bound='0.50') }} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" %} |
There was a problem hiding this comment.
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!
Co-authored-by: Daniel Ching <carterbox@users.noreply.github.com>
Co-authored-by: Daniel Ching <carterbox@users.noreply.github.com>
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. |
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. |
There was a problem hiding this 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.
Sounds good, thanks for the analysis, caution, and approval. :-) |
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 andpsi4_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
Source is from official source.(See notes above)If static libraries are linked in, the license of the static library is packaged.(No static libs)url
) rather than a repo (e.g.git_url
) is used in your recipe (see here for more details).