-
Notifications
You must be signed in to change notification settings - Fork 10
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
Build HEAD of v2.10 branch, enabling metatensor #5
base: cecam-2023
Are you sure you want to change the base?
Conversation
Thanks @Luthaf !!! Shall we have an explicit dependence on libtorch in |
It would also make sense to customize the label If this contains everything, we might call it |
There is already a transitive dependency on libtorch through metatensor-torch, but I can add an explicit one if you prefer!
Sure, I'll customize the label! |
Is there a way to also build py-plumed from this repository? Since I would need a version with plumed/plumed2#1129 included for the tutorial. If not, I can also try to run the simulation using some plumed-enabled LAMMPS build. |
Traditionally we didn't, mostly because it was not necessary. But you can add it. I think it makes sense if the python package for the tutorials is different from the official one. Otherwise, it should not be necessary |
So I sould copy the code from https://github.com/conda-forge/py-plumed-feedstock/ here and adapt accordingly? |
Ok, this has been changed to build the HEAD of v2.10 branch, and now includes py-plumed as well. |
It prevents local builds if the macOS SDK are installed in a different location
Updated to pull from https://github.com/plumed/plumed2, at commit plumed/plumed2@b0ffcb5 |
py-plumed/meta.yaml
Outdated
@@ -0,0 +1,52 @@ | |||
{% set name = "py-plumed" %} | |||
{% set version = "2.10" %} |
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.
Is there a standard way to make sure the date is baked in the version in some way? What I am thinking about is if a few weeks we release 2.10 it should override this one. Or shall we just increase the build: number below?
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.
If you look below, the actual version ends up being 2.10.git.<hash>
. I'm not sure if this will be treated as an alpha version by conda, but I can check that. If that's the case, the future 2.10 release should have priority over the alpha release!
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.
Ok, I changed this to have the version be 2.10.dev1
and store the git sha in the build string instead. The whole package is then plumed-2.10.dev1-git.b0ffcb55ad8cc3c71ec5c30a1bd46f68dd33bceb
.
This means that when 2.10 is released, it will be used instead of this one, since conda is following PEP440: https://peps.python.org/pep-0440/
macos-13 is the one to use for x86_64
CI failed trying to pull binutils on macos (to build lammps & gromacs). Not sure why this is needed though, they don't seems to be used by the build script. |
@GiovanniBussi could you start the CI so I know if it is now running or needs more changes? Thanks! |
@Luthaf thanks! I am not 100% about the gmx update. The fact is that some method that we are using in some tutorials is not supported by gmx 2024. Is this something that you would like to include because of specific features or just because of performances? If it's the latter I would suggest to stay with an older version. Thanks! |
So the issue was that plumed v2.10 is no longer able to patch gmx 2020.4, so I updated to the latest. But if this is a problem, I can update to the oldest version supported, I seems to be |
Also, the build currently fails on macos-x86_64 with I think this is related to the sdk version, which is fixed to 10.13 here: https://github.com/GiovanniBussi/conda-ci. Any chance you could update it? I think 10.15 should be enough, but at this point I doubt there are many users still on 10.15, and it could make sense to use 11 for both x86_64 and arm64. |
I can double check if it does not break other stuff.. I guess you can also replace ./conda-ci with ./conda-ci --sdk=11.0 |
2014b54
to
4f92469
Compare
Otherwise the log is too big to be viewed
Ok, everyting builds fine on my fork, could you start CI here as well? I had to swap to gromacs 2023.5, since 2022.5 fails to build with very strange errors (like |
Ah, I forgot to check the tests, and only did the build on my fork. Well, back to it! |
Creating this as a draft PR for @GiovanniBussi to comment on
This will need plumed/plumed2#1122 and plumed/plumed2#1123 to be merged first, and is currently pulling from a plumed fork with both PR merged. I'll update to use from plumed master later!