[go-nuts] scripting in Go
sc is a convenience package to support writing short automation scripts that simply panic on errors. It is similar to shell scripting with "set -e" option. https://pkg.go.dev/github.com/egonk/sc I wrote the package to stop copy pasting trivial helpers in throwaway and build automation scripts. Obviously panics instead of errors are not recommended for Go code, but I saw no big benefits by writing elaborate error messages in such scripts. M (generic Must) does not show on pkg.go.dev, probably because generics are not yet enabled. P (Printf) and PE (Fprintf os.Stderr) are currently not detected by go vet as printf funcs, is there a way to mark them in the package as printf? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8ad6fb22-ad25-4df7-8116-6615175d5a33n%40googlegroups.com.
[go-nuts] Re: scripting in Go
Thanks for the feedback! I can't say I disagree and I half expected the points you mentioned. Out of all the wrappers, P and PE admittedly give the least value. I placed more weight on these factors: - compared to the deployed production code that I'm working with (basically carved in stone and passed from programmer to programmer), supporting scripts are read less often and are usually thrown away or rewritten when the pipeline changes - out of the box Go makes it easy to ignore errors from functions like os.Chdir which are critical in scripts, so I wanted to make it extremely convenient to write error checks even when used without IDEs and linters - I'm a vi fan and there was a time when ex/vi was new and people learned the cryptic keystrokes anyway :) On Tuesday, January 25, 2022 at 10:10:09 AM UTC+1 Christoph Berger wrote: > Thanks for sharing your package. > > To me it seems that the functions are rather shallow wrappers around other > single functions from the standard library (e.g., sc.P() maps 1:1 to > fmt.Printf()). You certainly save a couple of keystrokes while *writing* > a script this way, but on the other hand, *reading* the resulting code > adds cognitive overhead, as you need to go one extra step from recognizing > stdlib functions (fmt.Printf) to recognizing custom lib functions and their > mapping to the underlying stdlib functions ("ok, there is a sc.P() in this > script, this maps to fmt.Prinft()..."). > > This is super ok if you write throwaway scripts for your own purpose, but > once you pass the scripts around, the receivers would have to learn a new > pacakge API and read through an extra API layer to see what the script is > doing. Remember that code is much more often read than written. > > If the main purpose is to eliminate explicit error handling (which is > *perfectly > fine for simple scripts* IMHO), then I would at least prefer longer > names, like sc.Printf(), which would make the purpose of this function > obvious. > > Just my $0.02. Otherwise, I generally like the idea of providing a > simplified API for supporting quick&dirty throwaway scripting in Go. > Remember what Kelsey Hightower said: "Bash is the reason people leave IT"! > :-) > On Monday, January 24, 2022 at 12:32:48 PM UTC+1 eko...@gmail.com wrote: > >> sc is a convenience package to support writing short automation scripts >> that simply panic on errors. It is similar to shell scripting with "set -e" >> option. >> >> https://pkg.go.dev/github.com/egonk/sc >> >> I wrote the package to stop copy pasting trivial helpers in throwaway and >> build automation scripts. Obviously panics instead of errors are not >> recommended for Go code, but I saw no big benefits by writing elaborate >> error messages in such scripts. >> >> M (generic Must) does not show on pkg.go.dev, probably because generics >> are not yet enabled. P (Printf) and PE (Fprintf os.Stderr) are currently >> not detected by go vet as printf funcs, is there a way to mark them in the >> package as printf? >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/a57d878a-bca8-4ad6-b1db-e073bbab755en%40googlegroups.com.
[go-nuts] Re: scripting in Go
Good ideas, I added explanations for the shorthands: https://github.com/egonk/sc/commit/257d48f5ba187082ffb6a9b8b9d326eca26cb787 W or Wrap comes from the classic errors.Wrap (https://github.com/pkg/errors) Long forms might be added in a different package in the future (like github.com/egonk/sc/long/sc) because short form is specifically designed to work with dot imports. I am not sure if having two different names for everything is a good idea though, it could be even more confusing? I don't plan to add any extra functions to the package so learning these 9 should be enough for the foreseeable future. Unless some extremely useful func comes up of course :) On Tuesday, January 25, 2022 at 10:40:24 PM UTC+1 corin@gmail.com wrote: > > For my money, as a newcomer to the API, having both the long named > function and the shorthand would be useful. I can see myself using M > immediately, but some like W I'm not likely to remember as readily and > longer names would help in adopting the library. (Also, what is the > mnemonic for W?) Afterall, commands in vi have a long form and short forms. > On Monday, 24 January 2022 at 10:32:48 pm UTC+11 eko...@gmail.com wrote: > >> sc is a convenience package to support writing short automation scripts >> that simply panic on errors. It is similar to shell scripting with "set -e" >> option. >> >> https://pkg.go.dev/github.com/egonk/sc >> >> I wrote the package to stop copy pasting trivial helpers in throwaway and >> build automation scripts. Obviously panics instead of errors are not >> recommended for Go code, but I saw no big benefits by writing elaborate >> error messages in such scripts. >> >> M (generic Must) does not show on pkg.go.dev, probably because generics >> are not yet enabled. P (Printf) and PE (Fprintf os.Stderr) are currently >> not detected by go vet as printf funcs, is there a way to mark them in the >> package as printf? >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/9adff0f8-d9ac-4437-ac93-6eb377f6779en%40googlegroups.com.
[go-nuts] Re: scripting in Go
I made a second variant in a separate repo/module: https://pkg.go.dev/github.com/egonk/scr The function names are more descriptive, Printf wrappers were removed and it is not meant to be used as a dot import anymore. On Monday, January 24, 2022 at 12:32:48 PM UTC+1 eko...@gmail.com wrote: > sc is a convenience package to support writing short automation scripts > that simply panic on errors. It is similar to shell scripting with "set -e" > option. > > https://pkg.go.dev/github.com/egonk/sc > > I wrote the package to stop copy pasting trivial helpers in throwaway and > build automation scripts. Obviously panics instead of errors are not > recommended for Go code, but I saw no big benefits by writing elaborate > error messages in such scripts. > > M (generic Must) does not show on pkg.go.dev, probably because generics > are not yet enabled. P (Printf) and PE (Fprintf os.Stderr) are currently > not detected by go vet as printf funcs, is there a way to mark them in the > package as printf? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/8fc7039f-0420-41a6-b7f9-a25f7f10c52cn%40googlegroups.com.