There currently is no good way to do this from within a single repository created with this template. My approach has been to use one repo per year. The only thing that has to be set up again for the second repo is github action secrets for the star tracker. One advantage - for me - is that I can change the lib code between years w/o having to touch my older solutions. I concede that this approach is awkward if you want to cherry-pick problems from different years and not go through a single year in a linear fashion.

The reason this is difficult to implement is that we are using ./src/bin to skirt around having to deal with either a cargo workspace or the module system (more context here if interested) and src/bin does not allow nesting folders currently. Another problem is getting the star tracking to work in a multi-year context.

I'm leaving this issue open as it would be nice to support this, also to gauge interest. We may eventually get there if we end up switching to a different code layout for the template.

As part of #19, the manual --year flag will be replaced by an env flag in .cargo/config.toml:

[env]
AOC_YEAR = "2022"

this should make it a bit more convenient to use the template for solving past years.

One thing I did was rethink how solutions are organized entirely, basically treating each solution as its own separate project, this has the downside of making accurate benchmarks practically impossible (since "running a solution" involved executing the solution executable with a cli argument specifying what part to run (part one or two), any benchmarks will include all the overhead of executing the process through the languages build system), but allows us to use the same cli and repo for multiple languages (currently support rust, python, and zig) and years.

Though now that I think about it, if the goal is just multi-year support you could just change the naming conventions of the solutions to include the year, and making some obvious adjustments to how inputs/puzzles/examples are handles in the data directory (put in folders by year)

the star tracker is a more complicated issue though.

I pretty much created the repo from the template and then immediately set up a branch for 2023. You can make the GitHub stars action run on the specific year branch and that will only update that one branch. So far no downsides for me ^^ The only thing you need to adjust for is the Actions secret, but that could be easily factored out as well.

I'd be interested in multi-year support, as I like to reuse and continually improve tools year over year. The module approach seems reasonable to me and I didn't find it too difficult to pick up when starting Rust. Modules can also map one-to-one to separate files, so for [Rust] beginners, it will feel quite similar to the current model in this template of one file to implement per day.

I think the approach also opens the door to separating the tooling in this repo into a separate crate such that people solving puzzles continue having two functions to implement in a file, just like it is now, but their repository instead pulls a dependency on this crate with a "magic" main.rs with a macro:

advent_of_code::main!()

It can then be integrated into any other crate if the developer so chooses, perhaps as a new binary or their crate's main binary. All of the tooling and well-crafted CLI of this crate is available, but still a ton of flexibility for how the rest of their personal AOC crate is structured.

the approach also opens the door to separating the tooling in this repo into a separate crate

FWIW there is cargo-aoc already which kinda works like this.

I pretty much created the repo from the template and then immediately set up a branch for 2023. You can make the GitHub stars action run on the specific year branch and that will only update that one branch. So far no downsides for me ^^ The only thing you need to adjust for is the Actions secret, but that could be easily factored out as well.

Wouldn't this overwrite the data/inputs and data/puzzles on every year (branch) switch since they're not tracked by Git? Also the target would be overwritten on every recompilation.

What about letting binaries have the name format {year}-{day:02} instead of just {day:02}? It still maintains the sorting characteristics and can be made backwards compatible since the runner can discern between the two.

Thanks for this PR @PaulTreitel ! We followed different paths and I tried to highlight key differences :

Pros of #77 :

• Doesn't duplicate source files of the tool (with 78, each update of advent-of-code-rust will not be propagated to existing source files in years folders)
• Compatible with stars (even though, with work on 78 it could be supported, even display all years)

Pros of #78 :

• Better for GitHub pulls and pushes (77 cause many file changes if year switches between commits)
• Definitively cleaner, and surely safer for users.

• try command seems very useful, cargo test is not a good solution to check examples for a day.