Thanks again Bit of background, I've been playing with go on and off for five or six years. I have decades of experience in various systems programming languages, including things like TOPS-10 macro, c, bliss, etc. Go is very attractive to my systems-internals side. About five years ago I started writing some go programs that were typical shell programs that two decades ago I would have written in perl. Thus the "cmd" directory since in the windows world at the time, you ran in the 'cmd shell'
I've recently got the bug again to write some go. Over the years, go has changed, and example programs on the web have changed. So what I am copying from has various vintages and has code from many sources, some of which may be very obsolete. On Saturday, November 19, 2022 at 3:15:08 AM UTC-5 Brian Candler wrote: > But you don't need to split into multiple subdirectories at this point: > only multiple files in the same directory. (Unless you're talking about > separate executables, in which case, yes they need to be in separate > subdirectories). > Yes, I was specifically talking about creating separate executables. So one subdirectory for each separate executable it shall be. > Do I really need to have the source code deeply burried in names that tie >> it all to my github repository? >> > I'm not sure what you mean by that. All the source files in the same > package (in the same directory) don't need to import each other at all, so > they do not reference each other by module name. > I am in the habit of sharing all of my code, with github being the sharing technique of choice over the past decade or so. > The module name is used when you need to import code from somewhere else. > If you choose a module name that links to your github repository, then > other people will be able to import your module using that name, and the > code will be fetched and built automatically. > That is what I want to do. I want folks to be able to use my code if they want. But the naming of the subdirectories with the full path to my github reposities is fairly ugly and cumbersome. > I'm using >> ~/sandbox/gows/src/github.com/pfarrell51/cmd >> because "gows" is "go work space" with src code >> > > Be careful with your terminology here: there is a specific feature called "go > workspaces <https://go.dev/doc/tutorial/workspaces>", but this has only > been recently added and is an advanced topic (for working on very large > projects) and you should ignore it for now. > Somewhere along the line, some example years ago talked about a go workspace, so I invented the gows subdirectory. > Incidentally, there is no need to have github.com in the directory path > on your local filesystem. You could just use > ~/projects/cmd > Doesn't this contradict putting the github path in the name for easy automatic use? Or am I confusing two issues? If the "foo" and "bar" executables are completely independent and don't > share any code, then I would publish them as separate repos, each with > their own go.mod. > So far, they have all been completely independent, but that is mostly because in go, I'm a rookie and nothing I've written is very substantial. > Note that import "github.com/pfarrell51/cmd" doesn't mean "fetch this > code from github". It just refers to the module's name. By walking up the > parent directories and finding go.mod, Go realises that the named module > you are referring to is already on your filesystem as part of your project, > and uses that directly. This is why it works to use random module names > like example.com/test > I'm not following this, I thought that was exactly why I put in the " github.com/pfarrell51/< <http://github.com/pfarrell51/cmd>modulename>" in the source directory structure, and therefor in the github https://github.com/pfarrell51/gows repository so if someone wanted to use my PID code or my quaternion code, it would be easy and automatic Thanks Pat -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/dd7a4e05-28a0-4264-b6db-f689a6684859n%40googlegroups.com.
