Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feat] Build hooks #40

Closed
MrPixelized opened this issue Dec 22, 2023 · 4 comments
Closed

[feat] Build hooks #40

MrPixelized opened this issue Dec 22, 2023 · 4 comments

Comments

@MrPixelized
Copy link

Customizable build hooks, e.g. to fetch information from the host OS when building, do things differently based on the environment, etc.

First idea for how the configuration of this would look:

An mcman repository would get an optional hooks/ folder, containing any number of files, to be named freely by the user.

The server.toml file will get a new section:

[hooks.{filename}]
when = "post" | "pre" | "post_unpack" | ...
onfail = "error" | "ignore" | "warn"
output = "show" | "hide"
description = "Fetch current admins from a matrix chatroom and /op them in every world"
env = { default_admin = "john" }

When running mcman build, each file in the hooks folder named after a corresponding "hooks" subsection in server.toml will be executed at the specified "when" moment. The description would be displayed to the terminal for every hook.

Each hook executed will get access to some environment variables, which will depend on the settings specified in server.toml, such as the "env" setting, as well as the "when" setting (e.g. a post_unpack hook would get the folder to which a world has been unpacked passed in some environment variable).

In this proposal, arguments to programs go unused.

@TheAlan404
Copy link
Contributor

that's a solid config format! i guess we can add extra metadata (such as the world being unpacked) as environment variables to the child process.

im still skeptical about the platform compatability though, bat and sh dont mix very well

maybe it can be like so: hooks/meow.sh and hooks/meow.bat - would be defined as [hooks.meow] in the config and mcman would pick the correct file depending on the OS

@MrPixelized
Copy link
Author

MrPixelized commented Dec 23, 2023

However, .py scripts would work the same on both. To avoid having to code a million edge cases for incompatible-but-similar programs (e.g. windos binaries, POSIX binaries, MacOS binaries), how about we add the option of manually specifying platform-dependent options?

So if you have a cross-platform script (e.g. .py), or you're not interested in cross-platform compatibility (such as a lot of users), you don't do anything else, but if you are, you just do:

[hooks.meow]
platforms = { windows = "meow.bat", linux = "meow.sh" } # Unmentioned platforms will default to the name specified by the subsection, namely just "meow"

This would mean you could make your configuration as you want (e.g. just call your script "meow" on unix), but if demand falls upon you to fix cross-platform compatibility, it is easy to do (add a meow.bat, and add platforms = { windows = "meow.bat" } to the [hooks.meow] section - NO need to rename the original file, which might already be expected in its previous form by build/test pipelines and such). Forcing people to give their scripts particular names also runs into other edge cases, such as someone wanting to use a .sh file on windows.

An alternative syntax could be something like:

[hooks.meow]
windows = "meow.bat"
linux = "meow.sh"

Once again with the option of leaving any platforms missing and having the default meow script be called.

@MrPixelized
Copy link
Author

Another way of fixing cross-platform compatibility that I considered mentioning in the issue itself is to run the build hooks in a container and mount the whole mcman repository into it. The problem with this approach is that you don't know what someone would want to do. Maybe it's more than just change a couple of files, maybe they want to send a notification to their phone that the build is completed (e.g. if they have extremely slow internet and/or a lot of huge worlds), or whatever other use cases we cannot think of. This "outside the repository" use would need to be facilitated by editing the container specification, and we can't expect everyone who just wants a script to run to be good at working with containers, which are a divisive technology anyway.

TheAlan404 pushed a commit that referenced this issue Jan 31, 2024
@TheAlan404
Copy link
Contributor

It's now implemented, will release 0.4.4 soon! :3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants