Proposal: rename module and package

[myitcv]

Firstly, thank you very much for starting this project. Your blog post inspired me to try and take the idea further:

https://blog.myitcv.io/2020/02/04/portable-ci-cd-with-pure-go-github-actions.html

I wonder, however, whether in these v0 days we should consider a different module path and package name:

github.com/sethvargo/go-githubactions has the disadvantage that:

• the base of the import path does not match the package name
• the package name, githubactions, is rather long

Options we have:

1. Change the module (and package) path to github.com/sethvargo/actions
2. Switch to a vanity URL (so that the backing VCS repo can be named whatever we like): sethvargo.com/actions

Thoughts?

[sethvargo]

I'm a fan of descriptive package names.

1. Go automatically handles the go- prefix, so the package name is just githubactions - this is quite common in the Go ecosystem

2. actions is really generic and will likely conflict with other things in any real-world use

3. You can always alias it yourself:

   import (
     actions "github.com/sethvargo/go-githubactions"
   )

4. I don't like vanity URLs because it makes it hard for users to find the true source of truth

Thank you for the feedback, but I'm going to keep it as-is 😄

[myitcv]

Thanks for taking the time to respond.

I'm a fan of descriptive package names.

Indeed, but I think there is something to be said for the import path also conveying meaning/scope too. So I would find:

github.com/sethvargo/github/actions

preferable for example.

As I understand it, people use a go- prefix for the base of the import path as a means of easily distinguishing between Go and non-Go repositories in your VCS (GitHub) and in, say, Google search results: is that true here?

Vanity import paths are, to my mind, cleaner: because they abstract away from where code is stored/maintained. Tools and sites like https://pkg.go.dev could and should, I agree, make it easier to quickly navigate from import path to source location. I also have hopes that pkg.go.dev will improve things on the discoverability front too.

2. actions is really generic and will likely conflict with other things in any real-world use

I think the context is important here because it's more a question of whether we are likely to use another package called actions in the course of writing a GitHub action in Go.

And if there were a clash, then an import path like:

github.com/sethvargo/github/actions

would at least allow us to alias one of the packages to another name and still know exactly which package we are referring to in either case.

FWIW, https://godoc.org/?q=actions shows 18 packages named actions (I used godoc here because partial matching in pkg.go.dev is still not 100%: golang/go#36806)

3. You can always alias it yourself:

   import (
     actions "github.com/sethvargo/go-githubactions"
   )

Yes, I was aware of this - thanks.

4. I don't like vanity URLs because it makes it hard for users to find the true source of truth

Per above, I think pkg.go.dev (and other such tools) should improve things on the discoverability front: the package name is one element that contributes to a hit score, just as the remainder of the import path and documentation convey details too.

Thank you for the feedback, but I'm going to keep it as-is 😄

I appreciate the exchange in any case, thank you.

[mvdan]

Just as a data point, we have packages like text/template, and it's OK that the name is a bit ambiguous. One can always do import texttemplate "text/template" if they happen to import lots of templating packages in the same file.

[github-actions]

This issue has been automatically locked since there has not been any
recent activity after it was closed. Please open a new issue for
related bugs.