Skip to content

Conversation

@muz
Copy link
Contributor

@muz muz commented Dec 29, 2025

I wrote a small script that would fetch set information from the Scryfall API (can include in a separate PR under Utils), and use this to consistently generate the cards.add calls for a given Set class.

The idea here being that it would be a handy way to quickly centralise in code what's missing or not from being implemented without the need of needing to go back and forth between Github and my IDE (without assuming the Github issue was truly up to date), but also to ensure that set data was correct, and deterministically ordered (by name and then collector number) for human-readability.

I've ran this script against a few sets already where the results seem safe and/or welcome. In most cases it's just reordered what was already there to be consistent. In some cases it's added in line comments for where we're missing card classes. In a few cases it's added in additional printing information that was previously overlooked and missing.

@github-actions github-actions bot added the cards label Dec 29, 2025
@muz
Copy link
Contributor Author

muz commented Jan 11, 2026

Closing this one out. While it was good as an exercise for me to learn a bit more about the codebase and workflow but I don't think it's appropriate to merge as-is.

While the tracking of unimplemented cards is not ideal with the potential for drift between Github and codebase, this is not the way to address that. There's likely a larger conversation to be had. That said, while not ideal, it's workable right now with the Perl scripts being runnable locally to get an idea of what's missing based on the current and actual state of the checked out codebase...

On items being ordered inconsistently, while a little jarring, it's not functionally problematic. Reordering based on how my local script is problematic though as it would be fighting with the actually established approach that's performed via gen-card.pl.

On missing print information, that should be independently called out and PRed in isolation from the other changes. Which I can circle back to doing later. Not a massive priority either.

@muz muz closed this Jan 11, 2026
@muz muz deleted the deterministic_set_data branch January 11, 2026 19:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant