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.
Can you expand on this a bit please? What does $host mean? Why would I need that for a purely local project that is only created for my own use?
And what about grouping projects? E.g. "personal", "work", etc. And where in the structure are languages? Is that the overarching directory?
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.
The "owner" could be multiple directory levels depending the hosting service. Gitlab lets you have arbitrary sub levels. The owner of the files also isn't necessarily related to the owner of the repo on Github.
sureglymop|1 year ago
bheadmaster|1 year ago
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:
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.
AlecSchueler|1 year ago
softirq|1 year ago