Define CopperLib scope

[aidnem]

Purpose
To extract as much reusable code as possible into a core library to minimize the amount of boilerplate and reused code.

This issue exists primarily as a discussion-place before we create the CopperLib repository. Once it's created, issues for features should be created there.

Note: the name CopperLib was the first idea that came to mind, we can use another name later

Project Scope

• Define scope of CopperLib (what features do we need?)
• Define which features will be in central layer (no WPILib) and which features will be in interface layer (WPILib integration)
• Create library (probably move into a separate github repo)
• Migrate 2024-Robot-Code to use CopperLib library features instead of implementations from this repository

Library Scope

• TBD

[aidnem]

@jkleiber we can begin adding everything we want to put in the library here, or we can just go ahead and create a GitHub repository for it first. I don't have any experience making Java libraries so it'll be a learning experience.

We may also want to split the core library and the interface layer into separate repositories, but I'm not sure how it'll pan out quite yet.

[jkleiber]

@aidnem we can build off of this: https://github.com/team401/coppercore

Once we have the scope defined, I think we have a couple parallel tracks:

1. Library integration:

• Create a git submodule in src/main/java/frc/robot
• Make setup instructions clear (need to clone with --recurse-submodules) and build simple tooling for making sure the correct submodule hash is checked out
• Update 2024 code to use the library functions, deprecate the 2024 functions

2. Build features per the scope (this is self explanatory). As part of this effort, we should add some CI/unit testing to ensure there aren't regressions in the library

[jkleiber]

@aidnem @linglejack06 coppercore is currently set up to be a vendordep rather than a submodule - does that still make sense?

I feel like learning how submodules work is more valuable than vendordeps, and they are much more flexible. Thoughts?

[aidnem]

@jkleiber @linglejack06 In my opinion it would be much simpler to just use a submodule than to deal with a vendor dep but that's just my initial impression. The only thing would be version checking (make sure we have the correct version cloned) but I'm sure that wouldn't be too difficult to handle.

[linglejack06]

@jkleiber @aidnem based on the little research I did, it seemed simplest to use the vendordep to add to gradle build. But sub modules seem easier honestly and better. So I'm cool with using submodules

[aidnem]

@jkleiber @linglejack06 Do you have any input on whether we should separate core layer from the interface layer within the coppercore repository or in 2 separate ones? It might be better to separate them into 2 different repositories so that we can update versions independently of each other. On the other hand, it would be simpler to have 1 repository over 2.

[jkleiber]

@aidnem I think it would make sense for the core library to define its interface so the dependency management doesn't get too complicated

[aidnem]

@jkleiber to clarify I meant the interface layer that handles communication with WPILib (so that we don't have to update core library when WPILib updates). We can still put that in the coppercore repository though.

[jkleiber]

@aidnem yeah I understood that - I think it makes the most sense to actively maintain the WPILib interface layer in lockstep with coppercore rather than having it on the robot project each year.

If wpilib changes, then coppercore just updates to handle it. Thinking a few years into the future, all robots that use coppercore will be locked to a specific coppercore version. Since robots don't typically go under active development after the next competition year, any additional features to coppercore don't need to be backwards compatible imo.