sesame2spiner refactor

[adamdempsey90]

PR Summary

This does some refactoring on the code base to build sesame2spiner as a library that singularity-eos links in while maintaining the executable sesame2spiner. sesame2spiner was linking in singularity-eos for some things, so I have moved those shared headers into a new library called singularity-utils. For backwards compatibility in downstream codes, I have replaced the headers lost in singularity-eos/base with forwarding headers to singularity-utils. I have updated the includes in singularity-eos proper with the new ones.

If I did everything correctly, nothing should've changed. So my plan is to have this MR merged, then follow up with adding the functions to sesame2spiner the library to process tables without reading a file.

PR Checklist

• Adds a test for any bugs fixed. Adds tests for new features.
• Format your changes by using the make format command after configuring with cmake.
• Document any new features, update documentation for changes made.
• Make sure the copyright notice on any files you modified is up to date.
• After creating a pull request, note it in the CHANGELOG.md file.
• LANL employees: make sure tests pass both on the github CI and on the Darwin CI
• If ML was used, make sure to add a disclaimer at the top of a file indicating ML was used to assist in generating the file.
• If Agentic AI was used, have the AI generate a "proposed changes" markdown file and store it in the plan_histories folder, with a filename the same as the MR number.

If preparing for a new release, in addition please check the following:

• Update the version in cmake.
• Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.
• Maintainers: ensure spackages are up to date:
  • LANL-internal team, update XCAP spackages
  • Current maintainer of upstream spackages, submit MR to spack

[adamdempsey90]

Evidently there's some cmake stuff left to figure it when things like spiner are not requested or when not in submodule mode maybe

[adamdempsey90]

This file is not included anywhere I think?

[Yurlungur]

No it's not. We could add it to the singularity-eos whole test harness after this refactor perhaps? I think that can be a separate MR.

[adamdempsey90]

Will do in separate MR

[adamdempsey90]

Evidently there's some cmake stuff left to figure it when things like spiner are not requested or when not in submodule mode maybe

Okay, all tests are passing now so I think this is ready for review

[buechlerm]

Is there an expected lifecycle for the forwarding headers? If so, how should we communicate to users that the forwarding headers are in place? Our changelog mostly just points users to MR's, but maybe in this case something more concrete about changes they should make? Issue a warning if the forwarding header is used?

[adamdempsey90]

Is there an expected lifecycle for the forwarding headers? If so, how should we communicate to users that the forwarding headers are in place? Our changelog mostly just points users to MR's, but maybe in this case something more concrete about changes they should make? Issue a warning if the forwarding header is used?

I see a few options:

1. I could add a #warning to those headers and then we delete them after they've been in place for 1 release. That could be communicated in the changelog for the next release.

2. I could just not have these at all and the next release is potentially breaking (I don't think that's a huge deal).

3. We always have the forwarding headers.

I don't really think people outside of us are going to act on the warnings, so I'm leaning towards option 2.

[Yurlungur]

I'm sorry for the long delay on this review. Some nitpicks below but they are all non-blocking.

[Yurlungur]

I guess this one needs the using statements.

[Yurlungur]

Could also consider moving this into ports-of-call... actually there may be duplicated functionality already...

[adamdempsey90]

Yeah, we can check

[Yurlungur]

Is there an expected lifecycle for the forwarding headers? If so, how should we communicate to users that the forwarding headers are in place? Our changelog mostly just points users to MR's, but maybe in this case something more concrete about changes they should make? Issue a warning if the forwarding header is used?

I see a few options:

1. I could add a `#warning` to those headers and then we delete them after they've been in place for 1 release. That could be communicated in the changelog for the next release.

2. I could just not have these at all and the next release is potentially breaking (I don't think that's a huge deal).

3. We always have the forwarding headers.

I don't really think people outside of us are going to act on the warnings, so I'm leaning towards option 2.

I am in favor of just making the next release breaking, but if we're worried about it I think a deprecation warning and then actually removing them one release later.

[adamdempsey90]

Is there an expected lifecycle for the forwarding headers? If so, how should we communicate to users that the forwarding headers are in place? Our changelog mostly just points users to MR's, but maybe in this case something more concrete about changes they should make? Issue a warning if the forwarding header is used?

I see a few options:

1. I could add a `#warning` to those headers and then we delete them after they've been in place for 1 release. That could be communicated in the changelog for the next release.

2. I could just not have these at all and the next release is potentially breaking (I don't think that's a huge deal).

3. We always have the forwarding headers.

I don't really think people outside of us are going to act on the warnings, so I'm leaning towards option 2.

I am in favor of just making the next release breaking, but if we're worried about it I think a deprecation warning and then actually removing them one release later.

I've removed them. They will show up as a rename in the diff now

[Yurlungur]

👍 merge when ready