0024 - Code stability, versioning - continuation

[JaGeo]

Continuation of #15.

Originally, I posted the following:

I am wondering if we could come up with rules, ideas to make our codes more stable for outside users? E.g., rules about breaking changes, release frequency and similar.

I have left out the proposal part so far as I have no clear idea on solutions just yet and I would love to discuss this

We have then been discussing a meta package as one potential solution. However, the workload has always been mentioned as a big con. To find out more about the workload, we then came up with the following action:

Suggested next action: prototype a meta package in a repo, possibly with a upload to test PyPI.

[JaGeo]

Instead of building a meta package, would it be feasible to add an optional workflow on the pymatgen, emmet repo etc to test against atomate2 so that breakages can be anticipated? (Pinging @janosh to see if there are further ideas). My feeling is that most of the breakages show up in atomate2.

[janosh]

since the atomate2 CI is constantly evolving and would cause extra maintenance burden to keep a copy in sync in pymatgen maybe better to trigger the actual atomate2 CI in its own repo on merges to pymatgen master (with the only difference being to install pymatgen from master). that could be done with a simple curl request from the pymatgen CI:

You can also trigger a GitHub Actions workflow from another GitHub Actions workflow by calling the workflow through the API. To do this, you can use the following command:
curl -L \ -X POST \ -H ``Accept: application/vnd.github+json'' \ -H ``Authorization: Bearer $(( secrets.GITHUB_TOKEN ))'' \ -H X-GitHub-Api-Version: 2022-11-28''

[JaGeo]

since the atomate2 CI is constantly evolving and would cause extra maintenance burden to keep a copy in sync in pymatgen maybe better to trigger the actual atomate2 CI in its own repo on merges to pymatgen master (with the only difference being to install pymatgen from master). that could be done with a simple curl request from the pymatgen CI:

You can also trigger a GitHub Actions workflow from another GitHub Actions workflow by calling the workflow through the API. To do this, you can use the following command:
curl -L \ -X POST \ -HAccept: application/vnd.github+json'' \ -H Authorization: Bearer $(( secrets.GITHUB_TOKEN ))'' \ -H X-GitHub-Api-Version: 2022-11-28''

This sounds great. My feeling is that this might be easier to organize than a meta package.

[JaGeo]

Within the meeting, we agreed that @janosh will try this on the pymatgen repository. We hope this is not too much effort and might therefore be more easily adapted for other important packages (e.g., the influence of emmet on atomate) than building a meta package.

[janosh]

@JaGeo i hope what i pushed in materialsproject/atomate2#835 and materialsproject/pymatgen@46b018d works, in which case atomate2 will raise an alert as soon as a change in pymatgen caused breakage

[JaGeo]

@JaGeo i hope what i pushed in materialsproject/atomate2#835 and materialsproject/pymatgen@46b018d works, in which case atomate2 will raise an alert as soon as a change in pymatgen caused breakage

Awesome. Thank you :). Let's just test it until our next meeting.

[JaGeo]

I would like to discuss whether we want to extend this workflow approach to other repositories. So far, the additional atomate2 workflow and additional testing with dependent codes (e.g., LobsterPy) successfully prevented breakages.

[JaGeo]

For now, we also discontinue the meta package solution (unless there is a new volunteer to test this)

[JaGeo]

During the meeting, we decided to test the workflow solution on emmet-core. Here, we will try to run the tests after new release candidates have been made.