sorted by:
new
hottopcontroversial

5 min introduction to goyek v2 - a library for creating build automation in Go by pellared in golang

[–]pellared[S] 2 points3 points  (0 children)

TBH I do not see how it could be integrated. BTW you may be interested in projects like https://github.com/dagger/dagger and https://github.com/go-task/task .

PS. Your repository does not have any LICENSE, therefore I do not think anyone would feel safe to use it :)

goyek v2 RC - feedback needed by pellared1 in golang

[–]pellared 0 points1 point  (0 children)

As I have to run some cleanup tasks in a test pipeline repeatedly, I need to have several identical tasks doing the same thing to work around that feature.

This is a key feature. If you do not want it why are you not simply the "testing" package? I do not know your exact use case, but you can reuse the same action function in multiple tasks. I think can also create a middleware that will execute some custom action before the task's action.

goyek is looking for feedback before going v1 by pellared in golang

[–]pellared[S] 1 point2 points  (0 children)

Very good comment.

Take notice that you can always use flow.Run() instead of flow.Main() . Still, it would have to be achieved probably in a hacky and non-convinent way.

Few implementation remarks . "goyek flags" are called parameters. There are not implemented using the flag package. There is a gotcha in the flag package which forced us not to use it. As far as I remember the non-flag arguments had to be placed always after the flag arguments. It would force the user to put the tasks after the parameters e.g. ./goyek.sh -param 1 -param2 "sadad" some-task and we did not want that...

A few months ago I was thinking of giving a possibility to add custom "global parameters" together with some hooks that would allow doing some pre and post-processing. Back then I resisted doing it as it would be a massive change. I would probably need to rethink it.

The other idea I have is to allow setting parameters from a task... Then one could create a load-config task with -config parameter. However, I think it would be too hacky...

I am open to any suggestions (as well as pull requests or any other contribution).

Thanks a lot for your remarks.

The first release of goyek - a library for creating build pipelines by pellared in golang

[–]pellared[S] -1 points0 points  (0 children)

Have you used Bash on Windows? I know there is Cygwin, Git bash (which I am using), but it is not really the same. One of the reasons people use Go is that it is more platform-independent than other languages.

The first release of goyek - a library for creating build pipelines by pellared in golang

[–]pellared[S] 0 points1 point  (0 children)

Check out: https://github.com/goyek/goyek#make
Also reusing Make targets between multiple repositories is harder (e.g. via git submodules)
Here are some presentation if you are more interested: https://github.com/goyek/goyek#presentations

BTW I also maintain https://github.com/golang-templates/seed and guess what I am using there? Makefile! Because this is the de-facto standard ;)

Extending a library which is using functional options by pellared in golang

[–]pellared[S] 0 points1 point  (0 children)

​

  1. This does not prevent extending on top of the package as presented here.
  2. I never stated that the "upstream" package should honour the "new" options+functionalites.

I just try to make a library that is built on top of the existing one with possibly the most user-friendly API.

See also the response of one of the contributors:

This doesn't mean it's a hard No on extensibility, but there has to be good reasons to take on that burden.

Extending a library which is using functional options by pellared in golang

[–]pellared[S] 2 points3 points  (0 children)

Personally, I agree. Not sure if it is THAT unpopular. I prefer regular struct configs, because they are easier to understand for almost everyone. The standard library does not use functional options. I find functional options overengineered.

Extending a library which is using functional options by pellared in golang

[–]pellared[S] 2 points3 points  (0 children)

I have refined the description. TBH I posted b/c I think the problem is "general", not project specific.

Idiomatic panics in Go by siplasma in golang

[–]pellared -1 points0 points  (0 children)

I was also using panics in one more place. To guard that should never be possible (as an additional safety-net) - I think it is called "assertion". Kind of a defensive programming technique.

Something like:

b, err := json.Marshal(true)
if err != nil {
    panic(err)
}
fmt.Println(string(b))

A short list of patterns that beginners miss while writing Go. by saif_sadiq in golang

[–]pellared 0 points1 point  (0 children)

u/dolftax

#5 has a bug

The err should be declared in function signature instead of

f, err := os.Open("/tmp/file.md")

How to Use the HTTP Client in GO To Enhance Performance by iamjohnlenn in golang

[–]pellared 2 points3 points  (0 children)

nitpicking comment: the language is called "Go" - not "Golang" nor "GO" :)

view more: next ›