myitcv / react

MOVED TO https://github.com/myitcv/x/blob/master/react/_doc/README.md
BSD 3-Clause "New" or "Revised" License
234 stars 17 forks source link

Make go modules-compatible and switch to mono-repo #116

Closed myitcv closed 6 years ago

myitcv commented 6 years ago

I'm planning to make all of my Go code hosted on Github vgo-compatible and in the process switch to a mono-repo.

Rough plan at the moment is:

Any one have any thoughts/concerns with this?

cc @mpl

ghost commented 6 years ago

sounds like the future.

If a developer is NOT using the new VGO vendoring approach are they going to be up the creek without a paddle though ?

On Wed, 4 Apr 2018 at 12:37 Paul Jolly notifications@github.com wrote:

I'm planning to make all of my Go code hosted on Github vgo-compatible https://research.swtch.com/vgo and in the process switch to a mono-repo.

Rough plan at the moment is:

Any one have any thoughts/concerns with this?

cc @mpl https://github.com/mpl

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/myitcv/react/issues/116, or mute the thread https://github.com/notifications/unsubscribe-auth/ATuCwnywdJpuhVVJobby9q7uHN5z7LGgks5tlKJxgaJpZM4TGj35 .

myitcv commented 6 years ago

For developers of myitcv.io/react, i.e. those who make changes to the myitcv.io/react/... code base; yes, they will be up the creek.

For users of myitcv.io/react, i.e. those who import/use myitcv.io/react/..., everything will continue to work the if you use "old go"; just as it will also work with vgo

Edit: slight tweak to wording from original post.

mpl commented 6 years ago

@myitcv Nice of you to try vgo out and experience the bugs for the rest of us. I have barely scratched the surface of the vgo posts, so I don't think I have anything interesting to contribute. And if I understand correctly, as a user of myitcv.io/react , nothing much would change for me, right? What's the pros/cons of keeping your current pkgs separate VS making them a monorepo with modules?

myitcv commented 6 years ago

Nice of you to try vgo out and experience the bugs for the rest of us.

🔨

And if I understand correctly, as a user of myitcv.io/react , nothing much would change for me, right?

Correct. Indeed nothing should change, regardless of whether you use regular go or the new vgo.

The one thing that will change is the remote repo for myitcv.io/react. I'll have a think about how to document that change, how to clean up etc.

myitcv commented 6 years ago

What's the pros/cons of keeping your current pkgs separate VS making them a monorepo with modules?

As a starting point (which I will update over time)

Pros:

Cons:

myitcv commented 6 years ago

For anyone interested, I'm maintaining notes as I go https://github.com/myitcv/x/wiki/Notes-on-migrating-to-a-Go-mono-repo

For now myitcv.io/react remains in its current location; a couple of blocking issues.

mpl commented 6 years ago

Have you started moving some things around? Because 'dep ensure' (in Perkeep) is whining that myitcv.io/gogenerate should be renamed to myitcv.io or something like that now. Or maybe it's unrelated and I hadn't noticed before?

myitcv commented 6 years ago

Hmm @johanbrandhorst also reported an issue via dep.

And it seems:

go get myitcv.io/react/...

is also now failing.

Apologies - I was trying to make these changes in an entirely non-breaking way. But it seems I failed to get sufficient testing on that. Will revert the changes to get things back and working.

myitcv commented 6 years ago

meant @johanbrandhorst - apologies @jbrandhorst

myitcv commented 6 years ago

Ok - I've just fixed things by repointing myitcv.io/gogenerate back to its original repo.

Also added a safety go get check in myitcv.io/react whilst the vgo migration is in flux.

And added a Travis cron job to build myitcv.io/react@master every day to catch things that fall through the net.

Thanks for the report @mpl and @johanbrandhorst.

mpl commented 6 years ago

Thanks, looks good now. (https://camlistore-review.googlesource.com/c/camlistore/+/15126)

myitcv commented 6 years ago

Quick status update here.

I'm still attempting to make this switch. Understandably given that vgo is "alpha" there are a number of things to be ironed out along the way.

Most critically from @mpl's perspective (indeed anyone who uses myitcv.io/react) is that myitcv.io/react and related GopherJS repos will not move to my vgo-enabled mono repo until GopherJS becomes vgo-aware.

So the initial migration will be "everything non-GopherJS related". Followed, at some time later, by "everything GopherJS related."

This split state of affairs should be fine so long as people are using Go 1.9.7 or Go 1.10.3.

myitcv commented 6 years ago

Ok, this migration has just happened.

Everything should continue to work as before, regardless of your Go version. The only issue you might hit is that the repo "position" within the myitcv.io/... namespace has moved. Whereas there was a repo at myitcv.io/react before, there is now just a single repo at myitcv.io.

Making the mono-repo go module aware will happen on a separate branch for now.

Would appreciate if people could ping here in case of any breakages. Will leave the issue open until I'm satisfied nothing is broken.

euank commented 6 years ago

This does cause dep ensure to consider a previously valid Gopkg.toml invalid since it no longer allows you to refer to myitcv.io/react unqualified.

For example, the following:

[[constraint]]
  name = "myitcv.io/react"
  revision = "bca7c66b77ed8a5b86fb77cff70914c4a7cc3ce5"

will result in

$ dep ensure
The following issues were found in Gopkg.toml:

  ✗ the name for "myitcv.io/react" should be changed to "myitcv.io"

ProjectRoot name validation failed

A user that encounters this error can fix it in one of the following ways:

  1. Updating to use myitcv.io as it suggests, including an update to the commit hash.

... and as far as I can tell, that's the only solution. Even explicitly specifying an old source causes it to complain (e.g. the following does not make dep happy).

[[constraint]]
name = "myitcv.io/react"
revision = "bca7c66b77ed8a5b86fb77cff70914c4a7cc3ce5"
source = "https://github.com/myitcv/react"
euank commented 6 years ago

@myitcv To phrase my above comment as a specific question:

Should we be rolling forwards our Gopkg.toml to the new project root configuration, or do you expect to go back and use a different approach given this one does turn out to break some configurations?

Since it has already been a week with no one else popping up on this thread, it seems to me like just rolling forwards with it makes sense, but if you can give an ack that that's the plan, that would be appreciated!

xref perkeep 17526

myitcv commented 6 years ago

@euank apologies for the radio silence.

Should we be rolling forwards our Gopkg.toml to the new project root configuration, or do you expect to go back and use a different approach given this one does turn out to break some configurations?

Yes, please do roll forward.

Apologies for the breakage here, but in the long run it will make things much easier for me, selfishly, to manage a mono repo.

Since it has already been a week with no one else popping up on this thread, it seems to me like just rolling forwards with it makes sense,

Exactly.

I'll leave this issue open for now just in case of any other issues.

cc @mpl

myitcv commented 6 years ago

I haven't heard anything on this so I'm going to close this now.

Not least because I've also just merged module support into my mono repo:

https://github.com/myitcv/x/pull/35

When running Go 1.11 (a build from tip to be specific), the dependency includes experimental Go 1.11 version of GopherJS that is available from https://github.com/myitcv/gopherjs/tree/go1.11 that is itself module-aware.

I'll also be archiving these now-redundant repos over the weekend, moving wikis etc to the mono repo.

mpl commented 6 years ago

@myitcv we've started moving Perkeep to modules as well (https://perkeep-review.googlesource.com/c/perkeep/+/17946). If we have any issues with myitcv/react, we'll probably see them soon.