Add support for butler

[idbrii]

Make it trivial to use makelove to push butler builds to itch.io.

Adds a new butler section with two parameters:

itchapp - the name of the app: username/projectname. publish_love - whether to publish the .love file (since it's not a target).

Remove butler from postbuild examples since we have a better way of doing that.

Test

Created a test project on itch and pushed win32, win64, macos, lovejs, love builds to it from Win10. Incremented version and pushed a new win32 build. Version numbers show as expected.

Play lovejs build in browser. Play from itch app.

Butler is not invoked when itchapp is not defined.

[idbrii]

@hollunder makelove's configuration is generally documented in makelove_full.toml so this commit includes documentation there which essentially points you to https://itch.io/docs/butler/. Logging in is the third step in their tutorial. It's done by magic link and a saved token, so makelove doesn't need to store or access any authentication information.

(Butler setup is super easy: install via itch app, run, open magic link, click button, done.)

Yeah, I'm using Windows so I look forward to hearing how well this works on Linux!

[pfirsich]

Why are the postbuild actions not sufficient here? I feel like having a dependency like that needs a good reason, because if butler or the a API (the command line interface and the token stuff) ever changes, makelove needs changes too. Any code also needs maintenance and I feel like by having it, a user doesn't even save much. I would say you probably need to read the butler docs anyway (for seting it up and auth) and you also need to add a line to your makelove.toml in the end.

[idbrii]

Advantages over postbuild:

• Two lines of configuration for each project. Single point of maintenance (makelove) instead of per game. Confidence posting updates to old games Just Works.
• postbuild steps don't know which targets were built, so you can't upload a specific build without editing your config.
• easier to get paths right. Passing strings correctly is easier when there's no shell in between. (Although PR needs fixing to handle spaces in path)
• postbuild steps don't include full paths or variables for the game name, so each project needs specific setup:
  • current postbuild: "butler push {build_directory}/win32/SuperGame-win32.zip pfirsich/supergame:win32 --userversion {version}"
  • ideal per-target postbuild: "butler push {target_build_zip} {target_name}:{target_platform} --userversion {version}"

Users could write a postbuild step that handles the above and parses the makelove.toml, but that's a lot of extra work. makelove could expose per-target post build steps (and include a .love target for Linux support), but still has many points of maintenance.

Any code also needs maintenance and I feel like by having it, a user doesn't even save much.

My biggest argument is that if butler changes and one person pushes a fix to makelove, then it's fixed for every user instead of all users maintaining their own postbuild in each of their projects. Although, I recognize the downside of putting the maintenance burden on you instead of the user.