Perhaps this design makes more sense for those who prefer to keep several unrelated projects together in a single monorepo, but that's not my preference.
Perhaps this design makes more sense for those who prefer to keep several unrelated projects together in a single monorepo, but that's not my preference.
~/src/$host/$owner/$repo
organization structure makes a ton of sense for every project and as long as you organize all of your languages into this one tree, everything just works.
In Go parlance, it would be the remote host where the repository is hosted, e.g. github.com, dev.azure.com, golang.org, etc.
> Why would I need that for a purely local project that is only created for my own use?
If nobody else is using your purely local project, and you're sure nobody will ever use it until the end of time, then I guess you could just use "~/src/$HOSTNAME/$USERNAME/$PROJECTNAME". Otherwise, it would be wise to setup a remote repository ahead of time.
Go has a strong opinion that, in this day and age of distributed computing, projects should be online-first, so they can be easily used as dependencies. One of the nice consequences of this opinion is that Go dependencies can just be specified in the import statement - e.g. using grpc dependency is just:
import "google.golang.org/grpc"
No need for pom.xml, requirements.txt, cmake.txt, or any other kind of dependency configuration. It just works (unless it doesn't, like with private repositories, in which case it requires some exotic configurations in ~/.gitconfig or ~/.netrc, but that's a whole other can of worms - for most public repositories I've used it works flawlessly).> And what about grouping projects? E.g. "personal", "work", etc.
Assuming you only use one repository hosting service and have one username, all your personal projects would be under "~/src/$PERSONAL_HOSTING_SERVICE/$USERNAME/", and your work would be under "~/src/$WORK_HOSTING_SERVICE/$WORK_ENTITY/" or something like this.
> And where in the structure are languages?
It isn't. That's either a bug or a feature. If it's a bug, you could just do the whole thing by language, e.g. "~/src/go/", "~/src/java/", etc.
...until the project decides to switch to another hosting provider. Which has happened more than once in the past; it used to be common to host projects in Sourceforge, for a while Google Code was common, now many projects are on GitHub, and it won't surprise me at all when another forge becomes the popular one. Individually, projects might switch between being self-hosted (in their own domain name) and hosted on a shared forge (using the forge's domain name).
IMO, it's a bad design. It forces the project's repository's location to become the project's official "name", that is, it mixes up location and naming. It's better to have an indirection layer to map the project name to the project location, like most other languages do.
Who takes care of the indirection layer when the upstream decides to switch to another hosting provider?
What do you do if they fail to update their name::location mapping, and the language doesn't provide a way to do it yourself?
At least in Go, when that happens we can just add a `replace` statement in the go.mod file:
replace example.com/foo/bar v2.35.0 => example.org/baz/bar/v2 masterOr decides their github username looks better with an upper case letter (https://github.com/sirupsen/logrus/issues/570). Or for people who use their real name as their github name, updating their username after marriage, divorce, gender transition or whatever.
Unruly apps that benefit from UID/GID regimentation can be constrained in this way. The whole app assuming ~amtgo is also helpful.
EDIT: I also remembered this useful advice on prefixing private shell scripts in your path with a comma: