Hi Ignazio,
Athens is one option, but there are also possible options depending on what you are trying to accomplish.
Could you say a few more words about your use case?
If you are doing something simple, like experimenting with creating a hello world module in something like /tmp/hello, then I'm not sure you would need to do anything special after you cd to /tmp/hello and create the go.mod file in /tmp/hello. A module is defined by a tree of Go source files with a go.mod file in the tree's root directory, so if you are inside /tmp/hello or a subdirectory, the go commands will find that go.mod file, and things should 'just work' (where all of that is on your local filesystem, with no direct tie to VCS or anything else).
If you are doing something more complex, some related questions might be-- are you creating these modules from scratch? If not, where are they coming from (GitHub, other VCS, manually copied, ___)? Is there a go 1.10 / GOPATH based workflow you already have that you are trying to map to a modules-based approach? Roughly how many modules?
The `replace` directive in go.mod is particularly flexible, and might be part of the answer. It gives additional control in the top-level `go.mod` for what is actually used to satisfy a dependency found in the Go source or go.mod files. One sample use case is if you need to fix something in a dependency, you can have a local fork and use a `replace
example.com/original/import/path => your/forked/import/path` in your top-level `go.mod` (without needing to update the import paths in the actual source code). The `replace` directive allows you to supply another import path that might be another module located in VCS (GitHub or elsewhere), or you can specify the location to be on your local filesystem, which might be what you are after here, but not sure.
In any event, sorry if this is not helpful or not very specific...
--thepudds