4 ms·

In maven, don't you need to update the pom file of the projects to point to the local copy? What's nice about the Go workspace system is that the workspace live

In maven, don't you need to update the pom file of the projects to point to the local copy? What's nice about the Go workspace system is that the workspace lives above the individual modules, meaning that the individual modules don't need any modification to pull in local dependencies. E.g. if your workspace looks like this: workspace/ mod1/ mod2/ Then both mod1 and mod2 will pull their dependencies remotely. But if you add a file to workspace/go.work, then local versions of mod1 and mod2 can be used without changing either mod1 or mod2.

metaltyphoon 4y ago
This is how a VS Solution is. You can have it anywhere in the file system and points to different projects. How those projects are on your file system its up to you (aka git clone, git submodule)
- doorman2 4y ago
  You can read about the VS solution format here: https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/extensibility... As you can see it's quite complicated. The contents of go.work is literally mod1/ mod2/ Also, the go.work file is meant to be your local workspace. If mod1 and mod2 have dependencies between each other, they should declare them explicitly and pull them in from the remote in most cases. The go.work file is only when you want to work on both modules locally. Meaning you don't check in go.work to your github repository in most cases.
  - metaltyphoon 4y ago
    Yeah the VS sln file is outdated and meant only to be used by the IDE. There are talks about revamping it, like the C# csproj had. I wasn’t aware about “not checking in go.work”. What if you want separate modules to be aware of each other but keep them in the same repo?
rad_gruchalski 4y ago
> In maven, don't you need to update the pom file of the projects to point to the local copy? Yes and no. It depends. You can use modules. With modules, each sub project lives in a directory under the root project. Maven reactor figures out the build order and all that crazy stuff. It’s the same with sbt and gradle.
0x445442 4y ago
See https://news.ycombinator.com/user?id=rad_gruchalski https://news.ycombinator.com/user?id=rad_gruchalski response

metaltyphoon 4y ago

This is how a VS Solution is. You can have it anywhere in the file system and points to different projects. How those projects are on your file system its up to you (aka git clone, git submodule)

doorman2 4y ago
You can read about the VS solution format here: https://learn.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2022 https://learn.microsoft.com/en-us/visualstudio/extensibility... As you can see it's quite complicated. The contents of go.work is literally mod1/ mod2/ Also, the go.work file is meant to be your local workspace. If mod1 and mod2 have dependencies between each other, they should declare them explicitly and pull them in from the remote in most cases. The go.work file is only when you want to work on both modules locally. Meaning you don't check in go.work to your github repository in most cases.
- metaltyphoon 4y ago
  Yeah the VS sln file is outdated and meant only to be used by the IDE. There are talks about revamping it, like the C# csproj had. I wasn’t aware about “not checking in go.work”. What if you want separate modules to be aware of each other but keep them in the same repo?

rad_gruchalski 4y ago

> In maven, don't you need to update the pom file of the projects to point to the local copy? Yes and no. It depends. You can use modules. With modules, each sub project lives in a directory under the root project. Maven reactor figures out the build order and all that crazy stuff. It’s the same with sbt and gradle.

0x445442 4y ago

See https://news.ycombinator.com/user?id=rad_gruchalski https://news.ycombinator.com/user?id=rad_gruchalski response