Closed rcoreilly closed 8 months ago
Strategy:
Another key point in favor of a monorepo: it means that you have easily reproducible and functional points in history. If you want to run the code at commit x
, you just have to run git checkout x
and you are done. With our current polyrepo system, it is basically impossible to do that, because there are tons of incompatible changes across many repositories, so you would have to manually pin down the correct version for tons of repositories. This also applies for end users: with a monorepo, if someone wants to use version x
in their app, they can just run go get goki.dev@x
. There is one unified version for the whole system that is guaranteed to work. With a polyrepo system, they would have to manage tons of dependency versions to do that. This is also related to the go.work
problem: because we are actively developing across multiple repositories, we have to have everything in a work file created with gsm work
. However, if someone else wanted to recreate that, they would have to clone every repository first and always keep them up to date. If they don't do that, their code doesn't build (and thus the CI also fails). Also, when developing apps outside of the goki organization, you need to manually make your own go.work
and keep it up-to-date with all of the new repositories we keep making, which is an unnecessary extra burden.
We are moving forward with this for the reasons listed above.
The codebase will be unstable during this change.
first pass completed! just need to update icons before merging into goki monorepo.
here's the script to prepare existing repo as a subdir:
#!/bin/bash -x
repo=$1
git clone https://github.com/goki/$repo
cd $repo
/bin/rm -rf .gitignore .goki LICENSE .github .travis.yml
git commit -am "cleanup"
mkdir $repo
mv * $repo
git filter-branch --index-filter \
'git ls-files -s | sed "s#\t#&$repo/#" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
git add $repo
git commit -am "add $repo files"
ls -la .
# in target repo:
# git pull ../$repo --allow-unrelated-histories
# git push --force
clearly the right way to go! Now in https://github.com/cogentcore/core
Proposal (from Kai and Randy)
Create a
github.com/goki/goki
repository that contains all of the dependencies forgi
up through the currentgix
extras repository, with the following exceptions:freetype
-- used byfyne
and potentially others -- maintained fork of go official package that got abandoned.vulkan
-- fork of package theoretically maintained by others and we'll probably transition to something else.We also need to decide about
gix
-- could draw the line atgiv
, which would reduce size and dependencies, but probably the marginal benefits there are not worth the cost of maintaining a separate repo. What aboutetable
?Also, what about:
ordmap
,glop
,grr
,gengo
, and possiblylaser
? See discussion below about major con of monorepo: makes it unlikely for others to be able to use these otherwise useful tools. Possible ways of "getting the best of both worlds" include maintaining separate stable versions of select repos, or just allowing others to effectively do the same thing by copying our code into their own projects.Cons of separate repos
gsm
tool to mitigate inherent slowness of dealing with so many repos (no single git pull, diff, etc) -- but it is still slow.go.mod
is stuffed withgoki.dev/*
entries.Cons of monorepo
enums
,gti
,goosi
,grr
,glop
etc) -- this is the most important motivation for having separate repos. OTOH, most of these things are most likely to be used in a GUI context (e.g., plain stringer is sufficient outside of enums). The main exceptions are:ordmap
,glop
,grr
,gengo
, and possiblylaser
.go mod tidy
in the new monorepo will get all of the dependencies for everything. OTOH, most of those dependencies are shared, and the theoretical savings would only apply to "optional" packages in gix, basically.Pros of monorepo
gsm
to mimic what we would otherwise automatically get from a monorepo. Our editors are rooted at the parentgoki.dev
level, replicating the directory structure of the proposed monorepo, except we now have a bunch of extra overhead files in every dir that would otherwise be gone.goki.dev/gi
vs.goki.dev/gi/v2/gi