Should we switch to go modules from dep

[mneil]

Idea

Mu is a bigger project that can be hard for new people to contribute to. Dep makes debugging hard when you fork the project for people new go Go.

Carlos Luna had suggested the idea because of my ease of use in migrating the crossing-go project to Go Modules. I found that any problems with Go path and dependency management issues relating to forked repos were no longer a problem and made developing/contributing much friendlier. My proposed value of migrating to Go Modules is simply to make it easier for newer Go developers to contribute to the project.

My Own Thoughts

• Go modules are still behind a flag. Won't be "released" until August
• No immediate value added to mu. Plenty of other things to work on

Conclusion

Go modules will be the future. There's no harm in moving to them now. If it lowers the barrier to entry and makes it easier to tackle future problems then go ahead.

On the call it was decided that @clunaslunas will fork the Mu project, migrate to modules and run all the tests after building the project. If nothing breaks, then push the changes to the forked repo and create a pull request. @mneil will review the pull request and verify non-breaking changes and merge the pull request.

It must solve the problem of testing the module from a forked copy of mu.

[srp]

In my experience, CDK is much easier to work with to achieve whatever outcomes are desired. However, it doesn't have a pipeline ready to go, and requires a bunch of work to figure out how to set one up. It would be really nice to have something like mu where most things are already setup with sensible defaults, but built up as CDK constructs so that a person can easily reconfigure or swap out parts as needed.