-
Notifications
You must be signed in to change notification settings - Fork 714
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
{tools}[foss/2023a] pyiron v0.5.1 w/ Python 3.11.3 #19398
{tools}[foss/2023a] pyiron v0.5.1 w/ Python 3.11.3 #19398
Conversation
Test report by @lcniel |
Test report by @lcniel |
Hmm, something broke when doing the from_pr build. Will have to check that later. |
@lcniel did you really intend to include all the other PRs in addition to |
I did, there's just a ton of dependencies that weren't updated upstream, with a lot of un-updated sub-dependencies... But this is becoming so complex that there's a risk that some of those dependencies will be covered by the time it's finished... I still haven't finished all the sub-sub dependencies on the plugins that turned out to be required 😭 EDIT: I saw now that there was an old, wrongly named |
@lcniel you can remove that erronesouly added easyconfig either from command line as described here or simply delete it in the GitHub web interface. Also, like @verdurin signaled, it is unusual to have this many easyconfigs in one PR. Generally, I would recommend splitting it up to give the reviewer (like me :)) a bit of an easier job. You can then open a Pyiron PR that depends on other PRs by putting this in the opening post, like was done in e.g. this PR. That way, we can process the dependencies in batches of 5 or so at a time. If there is some logical grouping (e.g. a Pyiron dep that itself requires 4 other deps), I'd bunch those together in one PR.
It also prevents this to some degree, since even if one of those dependencies has issues, at least the other PRs containing dependencies can already be merged. Finally, it also makes figuring out the CI issues a bit easier, as there are fewer changes per PR that can cause issues :) Let me know what you prefer. I'm willing to give it a go to review this PR as a single entity (after you've fixed the CI issues) if you feel a bit overwhelmed by having to split it now. But splitting it may lead to a faster merge in the end... :) |
Thanks a lot, then I will try to fix the CI issues. I only work with easybuild-related stuff 20%, so I don't have so much time to spend on this (basically the choice is between trying to fix it and abandoning it). I would never even have entertained taking this PR on if I had anticipated that it would grow like this and require this ridiculous amount of patching, or at least I would have done a much more modest toolchain/version move.
Thanks, I thought I did but apparently I forgot to commit it. Not totally used to the Github interface, I'm more experienced with Gitlab. |
…3.11.3.eb deleted erroneous rfile
moved Pint to deps
checksum fix
Test report by @lcniel |
Co-authored-by: Alexander Grund <[email protected]>
@boegelbot please test @ generoso |
@boegelbot please test @ generoso |
@ocaisa: Request for testing this PR well received on login1 PR test command '
Test results coming soon (I hope)... - notification for comment with ID 2158066816 processed Message to humans: this is just bookkeeping information for me, |
Test report by @boegelbot |
@boegelbot please test @ jsc-zen3 |
@ocaisa: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de PR test command '
Test results coming soon (I hope)... - notification for comment with ID 2158106746 processed Message to humans: this is just bookkeeping information for me, |
Test report by @boegelbot |
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.
@lcniel The merging of this PR is the EasyBuild gift to you for finishing your PhD 😛
Test report by @Flamefire |
(created using
eb --new-pr
)ETA: I have limited time to work on this and did not expect it to be as involved as it turned out to be, it should ideally be split up and merged as separate PR:s. Currently my available time to work on splitting this up is very limited as software building is only one aspect of a position I currently work one day a week at.