Repository navigation
Proposal: rename module and package #2
Description
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:
- Change the module (and package) path to
github.com/sethvargo/actions - Switch to a vanity URL (so that the backing VCS repo can be named whatever we like):
sethvargo.com/actions
Thoughts?
Activity
sethvargo commentedon Feb 6, 2020
I'm a fan of descriptive package names.
Go automatically handles the
go-prefix, so the package name is justgithubactions- this is quite common in the Go ecosystemactionsis really generic and will likely conflict with other things in any real-world useYou can always alias it yourself:
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 commentedon Feb 6, 2020
Thanks for taking the time to respond.
Indeed, but I think there is something to be said for the import path also conveying meaning/scope too. So I would find:
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.
I think the context is important here because it's more a question of whether we are likely to use another package called
actionsin the course of writing a GitHub action in Go.And if there were a clash, then an import path like:
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 usedgodochere because partial matching in pkg.go.dev is still not 100%: golang/go#36806)Yes, I was aware of this - thanks.
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.
I appreciate the exchange in any case, thank you.
mvdan commentedon Feb 6, 2020
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 doimport texttemplate "text/template"if they happen to import lots of templating packages in the same file.github-actions commentedon Aug 19, 2020
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.