feat: Decouple Python version and Go version

[yana1205]

Issue description / feature objectives

C2P has supported Python and Go. For Go, it's maintained under sub-directory (/go) and the Go module is referenced as github.com/oscal-compass/compliance-to-policy/go. It's better to separate the Go version in a different repository for maintainability.
(This is feedback from Raised by George Vauter (@gvauter ). Thank you for your feedback.)

Caveats / Assumptions

No response

Completion Criteria

Separate the Go version in a different repository

Related links

slack: https://cloud-native.slack.com/archives/C06F3PEPNBW/p1717786627638569?thread_ts=1717786588.204509&cid=C06F3PEPNBW

[jpower432]

@yana1205 Is this issue something I can assist with or work on?

[yana1205]

Thanks @jpower432,
I haven't been able to spend much time on this issue. Yes, it's helpful if you could assist.
I'm considering the following step to separate Go from this repository. Do you think this approach work?

1. Fork this repository into compliance-to-policy-go (or some proper name)
2. Remove the Python-related components and promote the 'go' directory to be the project root in the forked repository
3. Once go test passes, link 'go' directory in the original repository to the forked repository as a submodule for backward compatibility

[jpower432]

Hi @yana1205. Thanks for sharing your thoughts on the approach. I added some notes and questions below.

Forking makes sense to me to preserve the Git history. The name compliance-to-policy-go also makes sense 👍

I'm curious about the rationale for using a Git submodule in the original repository. Is the backward compatibility requirement due to users installing the Go module directly from this location, or are there downstream tools relying on the current repository structure with the /go directory? I believe a clearer separation can be achieved by maintaining Python in this repository and moving Go to the new one. What do you think?

[yana1205]

@jpower432
Thank you for your input. I have just realized that there is no risk in removing /go and we can completely separate it.
The backward compatibility concern was related to the idea that users who might specify the compliance-to-policy/go module in their go.mod file without providing a version could end up referencing the latest code, which would fail if I removed the go directory. However, since Go’s module system requires an exact version in the require statement, users will always reference a specific version of the code where the /go directory still exists.

[jpower432]

Thanks for the context @yana1205. It sounds like we are aligned on an approach. I will get to work on creating the fork.

• Fork this repository into compliance-to-policy-go
• Remove the Python-related components and promote the go directory to be the project root in the forked repository - WIP Pull Request feat: moves Go code and resources to repository root compliance-to-policy-go#1
• Once go test passes, remove go directory in the original repository (edited: Need detached fork)

[jpower432]

Step 1 Complete - https://github.com/oscal-compass/compliance-to-policy-go

[yana1205]

Thanks!

[jpower432]

@yana1205 I am still working to get this fully completed. I requested that compliance-to-policy-go to get detached so I can fork this repo. I realized it cannot stay an attached fork of compliance-to-policy because then you can fork one of them into your namespace.

[yana1205]

If I remember correctly, I wasn’t able to fork this repository when I opened a PR. Instead, I cloned it and pushed it to my account. Now I can fork this repository. It seems like keeping it detached is necessary so that people who have already forked c2p can also fork c2p-go. Thanks for the information.