work space

[ddkwork]

As an aside, a long time ago, I found a large repository that uses the workspace mode to manage Go modules. I read all your go repositories, nearly 70 of them, a few days ago I found that several of them have interface and struct object renaming, the change in the number of method return values causes gogi example compilation errors and gide compilation errors, currently I am going to come to a pr, however, there is also a repository after the change is completed, and this module has no fork, your repositories are too many, dependency updates and submit PRs are a bit troublesome, too many repositories are not easy to manage. If possible, create a large repository with a go workspace, and then merge all the repositories into the workspace, of course this will require changing a lot of module paths to make the modules clone correctly, I wondered if this would affect the release chaos of the respective modules, but it is possible to create a release collection. In this way, as long as one of the repositories of all repositories related to svg-related GRID, GI, KI, GOKI, etc. refreshes the code, we only need to right-click in the root directory of each repository to run go run test to check all unit tests, stress tests, fuzz tests, and a series of tests to reduce the maintenance work after refactoring the code of each repository, and wait until the main modules such as gi are stable and ready to be released, and then refresh all the module versions under the workspace at the same time.

[kkoreilly]

We have a tool, gsm, for managing the different goki repositories. We use go workspaces during local development; you can set up a full goki workspace with the following commands:

go install goki.dev/gsm@latest
mkdir goki
cd goki
gsm clone
gsm work

Then, you can run gsm pull, gsm changed, and gsm install-tools to keep your workspace up to date (and gsm clone and gsm work again whenever new repositories are added). Every time there are major changes, we run gsm release, which does a complete project-wide release cycle that updates and releases every repository after updating their dependencies, including on each other. Currently, we are making relatively frequent breaking changes, but once we release a stable v2, which should happen relatively soon, there will be very few breaking changes and there should be no more problems like those you mentioned. If you ever have those build issues, you can just ask me to do a release cycle, which will fix them, or you can make a workspace using the commands I mentioned.

[kkoreilly]

Also, all of this information will be documented on the website soon

[ddkwork]

We have a tool, gsm, for managing the different goki repositories. We use go workspaces during local development; you can set up a full goki workspace with the following commands:

go install goki.dev/gsm@latest
mkdir goki
cd goki
gsm clone
gsm work

Then, you can run gsm pull, gsm changed, and gsm install-tools to keep your workspace up to date (and gsm clone and gsm work again whenever new repositories are added). Every time there are major changes, we run gsm release, which does a complete project-wide release cycle that updates and releases every repository after updating their dependencies, including on each other. Currently, we are making relatively frequent breaking changes, but once we release a stable v2, which should happen relatively soon, there will be very few breaking changes and there should be no more problems like those you mentioned. If you ever have those build issues, you can just ask me to do a release cycle, which will fix them, or you can make a workspace using the commands I mentioned.

Perfect solution, thank you