search

oscal-compass / compliance-to-policy

Compliance-to-Policy (C2P) provides the framework to bridge the gap between compliance and policy administration.
Apache License 2.0
23 stars 16 forks source link

feat: Decouple Python version and Go version #22

Open yana1205 opened 5 months ago

yana1205 commented 5 months ago

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 commented 1 month ago

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

yana1205 commented 1 month ago

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 commented 1 month ago

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 :thumbsup:

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 commented 1 month ago

@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 commented 1 month ago

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

jpower432 commented 1 month ago

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

yana1205 commented 1 month ago

Thanks!

jpower432 commented 2 weeks ago

@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 commented 2 weeks ago

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.