zigup 2024.05.05 (new formula)

[quot]

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

This is my first formula, so please let me know if anything could be improved in the future.

The only thing I am unsure about is how the version (v2024_05_05) should be handled with this package. Based on brew audit testing, I know the v should be removed, but I am not sure about the underscores. I have replaced them with dots in the commit since that technically follows the commit style rules.

[github-actions]

Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

[SMillerDev]

We really shouldn't build an old version of a dependency. We should wait with this formula until zigup supports a modern zig instead.

[quot]

That's what I thought as well, but Zig is a bit of a strange case. There are major releases about every 6 months that break older builds. I would think the ideal solution would be to implement a [email protected] recipe for this, but I doubt maintainers would want beta versioned recipes in the repo.

Initially, I thought I would make this recipe a head only build since that is kept up to date with Zig, but I read that wasn't allowed somewhere.

This method of downloading an older version was pulled from the fastfec formula.

[SMillerDev]

That doesn't sound so strange to me, it just sounds like zigup isn't maintained to the standards that using Zig seems to require.

[carlocab]

fastfec built with the latest zig when it was added -- we almost certainly would not have added it if it required an older version of zig at the time. If fastfec still fails to build with the latest zig eventually, we will likely end up deprecating it soon.

[quot]

Well, while this was being discussed, Zigup made a new release on the latest Zig. I'll get this updated to build on that.

fastfec built with the latest zig when it was added -- we almost certainly would not have added it if it required an older version of zig at the time.

This is why Zig seemed like a strange case to me. As Zig gains popularity, I think this situation is going to occur more and more until a stable Zig version is released.

Even though this package wouldn't have built for 6 months, I wouldn't have said the package is unmaintained. Brew only has Zig 0.13.0, but 0.12.1 is technically a newer version. I don't know if [email protected] would be allowed since it's a beta, but it is a stable version that programs still rely on.

With all of that said, I'm fine with any decision you guys come up with for those situations.

[SMillerDev]

We need a test that exercises the some of the functionality of the app. Version checks or usage checks (foo --version or foo --help) are not sufficient, as explained in the formula cookbook.

In most cases, a good test would involve running a simple test case: run #{bin}/foo input.txt.

• Then you can check that the output is as expected (with assert_equal or assert_match on the output of shell_output)
• You can also check that an output file was created, if that is expected: assert_predicate testpath/"output.txt", :exist?

Some advice for specific cases:

• If the formula is a library, compile and run some simple code that links against it. It could be taken from upstream's documentation / source examples.
• If the formula is for a GUI program, try to find some function that runs as command-line only, like a format conversion, reading or displaying a config file, etc.
• If the software cannot function without credentials, a test could be to try to connect with invalid credentials (or without credentials) and confirm that it fails as expected.
• Same if the software requires a virtual machine, docker instance, etc. to be running.

[quot]

My bad, I actually meant to ask about this. The only functionality of this program that can be tested would be to download and install a Zig version with it. I was thinking it would be bad to have the test rely on an external resource, but I see you've mentioned that as one of your valid test cases. I'll get this fixed.