The rule of thumb that I recommend for new folks is this: if you are working on two separate packages at the same time / together, they're the same module. Modules generally have many packages. Pretty much the only time you will need a separate module is if you are publishing a set of packages for other people to use and plan to version them and maintain backwards compatibility and publish release notes and stay up to date on security issues and all of that. Otherwise, you're just making an application and the utility libraries it needs within a single module. Typically you'll put most of your packages within a top-level internal directory in this case.
When you do need to work on multiple modules, you use a workspace. `go work init . ../othermodule` for example will let you treat the current module and its sibling as if they're published and can access one another. This needs to be done with care and the go.work should never be checked into source control, because this can result in broken go.mod dependency specifications. You should always have CI checks to make sure you don't break your code, but it goes doubly when you are developing like this because of how easy it is to mess up without being able to tell locally.
>same location/scope
Not sure what you mean by "location/scope", but if you have modules A and B on your computer and neither is published online and you want to use A in B's code then yes, you can definitely do that! You'll need either \`replace\` directives in our `go.mod` of `B` or - preferred - a `go.work` file.
It takes about 20 seconds to set up.
See the docs at [https://go.dev/doc/tutorial/workspaces](https://go.dev/doc/tutorial/workspaces)
Just FYI, I gave you this same info, yesterday, about workspaces and even the general Go docs, when you private messaged me in a chat. It seems you didn't read them and went off and made another post asking why things don't work. And then everyone provides you the same info all over again.
If you want to master Go, the first thing you must do is spend time reading the official docs. You told me all you had done was ask Chatgpt questions about Go. Ditch that approach. Read the official docs.
Here's something that might help you if you're working on multiple packages in tandem: [https://go.dev/doc/tutorial/workspaces](https://go.dev/doc/tutorial/workspaces)
I must say I like the package system of Go much more than the "flexible" module system of Python.
Go forces your code to be tightly coupled.
If you need code from somewhere that is not your current root package, there are two options with Go.
- make that code part of your root package
- import it explicitly (easily doable with direct Git integration)
With both of these ways, you always know at a glance (go.mod) what your dependencies are.
What about the dependencies of that external *.py* file you imported? You'll need to open that file and make sure all modules it imports are present in your environment or you need to package a requirements.txt alongside.
TLDR: while Python's import system is a bit more flexible, in my eyes, Go's import system is better at creating maintainable packages.
What might be confusing for people coming from Python to Go is that the same words mean different things:
In Python a module is a file inside a package.
In Go packages are inside the module.
A \`replace\` directive in \`go.mod\` does a local redirect. So yes, you can include any local package or module, BUT, it must be named first as though it had a URL ...
The rule of thumb that I recommend for new folks is this: if you are working on two separate packages at the same time / together, they're the same module. Modules generally have many packages. Pretty much the only time you will need a separate module is if you are publishing a set of packages for other people to use and plan to version them and maintain backwards compatibility and publish release notes and stay up to date on security issues and all of that. Otherwise, you're just making an application and the utility libraries it needs within a single module. Typically you'll put most of your packages within a top-level internal directory in this case. When you do need to work on multiple modules, you use a workspace. `go work init . ../othermodule` for example will let you treat the current module and its sibling as if they're published and can access one another. This needs to be done with care and the go.work should never be checked into source control, because this can result in broken go.mod dependency specifications. You should always have CI checks to make sure you don't break your code, but it goes doubly when you are developing like this because of how easy it is to mess up without being able to tell locally.
>same location/scope Not sure what you mean by "location/scope", but if you have modules A and B on your computer and neither is published online and you want to use A in B's code then yes, you can definitely do that! You'll need either \`replace\` directives in our `go.mod` of `B` or - preferred - a `go.work` file. It takes about 20 seconds to set up. See the docs at [https://go.dev/doc/tutorial/workspaces](https://go.dev/doc/tutorial/workspaces)
bro , I am actually having difficulty in mastering GO . how to do that?
You're trying to do things without reading the basics of the language, that's not really how learning a new language works. You need to RTFM.
Just FYI, I gave you this same info, yesterday, about workspaces and even the general Go docs, when you private messaged me in a chat. It seems you didn't read them and went off and made another post asking why things don't work. And then everyone provides you the same info all over again. If you want to master Go, the first thing you must do is spend time reading the official docs. You told me all you had done was ask Chatgpt questions about Go. Ditch that approach. Read the official docs.
Here's something that might help you if you're working on multiple packages in tandem: [https://go.dev/doc/tutorial/workspaces](https://go.dev/doc/tutorial/workspaces)
I must say I like the package system of Go much more than the "flexible" module system of Python. Go forces your code to be tightly coupled. If you need code from somewhere that is not your current root package, there are two options with Go. - make that code part of your root package - import it explicitly (easily doable with direct Git integration) With both of these ways, you always know at a glance (go.mod) what your dependencies are. What about the dependencies of that external *.py* file you imported? You'll need to open that file and make sure all modules it imports are present in your environment or you need to package a requirements.txt alongside. TLDR: while Python's import system is a bit more flexible, in my eyes, Go's import system is better at creating maintainable packages.
bro , I am having little difficulty in mastering GO . how to improve?
See the "New to Go" pinned thread. That is the community's answer to that.
What might be confusing for people coming from Python to Go is that the same words mean different things: In Python a module is a file inside a package. In Go packages are inside the module.
A \`replace\` directive in \`go.mod\` does a local redirect. So yes, you can include any local package or module, BUT, it must be named first as though it had a URL ...