gtfs-validator
gtfs-validator copied to clipboard
Support for managing the binaries using brew
Describe the problem
Users of cli would have to download newer artifacts every time there is an update.
Proposed solution
Could we add support for installing using brew to allow users to manage the validator more easily? The process looks fairly straightforward: https://www.veracode.com/blog/secure-development/distribute-your-java-app-brew
Alternatives you've considered
No response
Additional context
Some things to consider:
- Would this become too much of a hassle in the long run?
- Are we trying to move away from cli and towards webapp only?
Thanks for opening your first issue in this project! If you haven't already, you can join our slack and join the #gtfs-validators channel to meet our awesome community. Come say hi :wave:!
Welcome to the community and thank you for your engagement in open source! :tada:
There would be advantages in using brew, but I am not sure it's a good return on investment at this point compared to just using the cli jar. @Neo2308 Can you tell us what advantages of using brew are important to you over just downloading the cli jar file?
BTW we are not moving away from the cli version. But we are looking into deprecating the desktop version: https://github.com/MobilityData/gtfs-validator/issues/1520
I do not use the cli version of this myself. But for any software, downloading the binary and using it is usually means that most people are probably not going to update it frequently (if ever). Whereas having it as a homebrew formula makes it way more likely that the users would be able to update it to the latest version.
Curious about other users' thoughts on this one. Tagging a few folks who have been active here as of late: @derhuerst, @wklumpen, @atvaccaro, @bradyhunsaker.
I use the cli version executed via Python actually which requires a bit of crossing of fingers.
That said, I don't mind the binary approach mostly because my development cycle is such that I don't really want to update the validator until I'm ready to accommodate any changes in output, error messages, reporting, etc. I also like the simplicity; getting a brew setup is one more deployment step I'd rather avoid.
But that's just my $0.02
No opinion. I hadn't heard of Homebrew, so I'm glad to learn of it. I am developing, so I rebuild frequently anyway.
The question seems to be how much this would help for users who aren't developing.