Future of the project

[jh-devv]

Challenges in Maintaining mc-modpack-kit

As the sole maintainer of mc-modpack-kit, I've encountered significant challenges in managing this GitHub Actions "template" project. Recently, I've been struggling to allocate sufficient time for its maintenance.

Please note: While I will continue maintaining this template for the time being, it's unlikely to be a long-term solution. I prioritize addressing the issues at hand first.

The Problem with GitHub Actions Complexity

As someone on HackerNews points out:

1. Program with github actions. Google "how can I send an email with github actions?" and then plug in some marketplace tool to do it. Your workflows grow to 500-1000 lines and start having all sorts of nonsense like conditionals and the YAML becomes disgusting and hard to understand. Github actions becomes a nightmare and you've invited vendor lock in.

2. Configure with github actions. Always ask yourself "can I push this YAML complexity into a script?" and do it if you can. Send an email? Yes, that can go in a script. Your workflow ends up being about 50-60 lines as a result and very rarely needs to be changed once you've set up. Github actions is suddenly fine and you rarely have to do that stupid push-debug-commit loop because you can debug the script locally.

For a detailed exploration of these issues, check out this video:

Moving Forward with Nix

Given the challenges posed by maintaining a GitHub Actions project, I'm considering a shift towards Nix, which has gained popularity recently. This move offers several advantages, including:

• Declarativity: Nix provides a declarative approach, which aligns well with modern software development practices. This contrasts with the procedural nature of GitHub Actions YAML files.

Benefits of Nix Integration

• Simplified Maintenance: By leveraging Nix with GitHub Actions, we can streamline our workflows and avoid the complexities inherent in managing sprawling YAML configurations.
• Version Pinning: Instances like issue #72, where dropping older versions caused inconvenience, can be mitigated through better version control and pinning offered by Nix.

The other actions like bumping versions could be simplified. A robust but simple pipeline could be achieved.

And as @logamaster said on the Discord:

I say make a simple one file action. It just reads a release from github and pushes the result.

So using the tag value, push to Modrinth and CurseForge or when a tag is pushed build and set up the result. This could be done with nix

---

Considering the challenges in managing a GitHub Actions project, I'm contemplating exploring alternatives like Nix, though the extensive rework required raises concerns about time constraints at least for me, since I have other stuff to do.