-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make docsy example site use docsy theme as hugo module #156
Conversation
✅ Deploy Preview for docsy-example ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
Finally, docsy example site now builds with hugo modules. You may have a look at the netfily preview and/or the deploy log. You also can test it out locally now:
In the next step, submodules can be removed from the docsy example site. I did this in another |
@deining - could you resolve conflicts when you have a minute (we're getting closer to merging this :)) |
Conflicts are resolved, the site now builds fine while using docsy theme as hugo module. 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See inlined question.
This is ready to go, right? |
Yes. Studying the deploy log I realized, that git submodules still get checked out. This doesn't do any harm, but it is not necessary either. Maybe this can be corrected? If so, I think we should open a separate ticket for this. |
OK, so the build instruction on Netlify is currently:
So will automatically check out the submodules. With Hugo Modules will it just work by running |
+1 to cleaning up the Netlify build commands to avoid getting/updating submodules for nothing. |
github.com/google/docsy v0.1.1-0.20220321183617-02df04c0f2d4 // indirect | ||
github.com/google/docsy/dependencies v0.2.0-pre.0.20220321183617-02df04c0f2d4 // indirect |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deining - can you help me understand the version IDs here?
- Why
v0.1.1-*
fordocsy
andv0.2.0-pre.*
fordocsy/dependencies
? - Shouldn't both of these be 0.2.0-pre?
- Is the
v
prefix to the module ID necessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can still go ahead and merge this @LisaFC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@deining - can you help me understand the version IDs here?
* Why `v0.1.1-*` for `docsy` and `v0.2.0-pre.*` for `docsy/dependencies`?
The same question for me.
* Shouldn't both of these be 0.2.0-pre?
Yes, it should!
* Is the `v` prefix to the module ID necessary?
The v
is not from me, it was auto-generated: All I did: on the command line, I entered hugo mod get github.com/google/[email protected]
, and go
auto-magically converted this into v0.1.1-0.20220321183617-02df04c0f2d4
. I don't like this either, but I left it as is.
I assume go expects something like x.x.x
and gets somehow confused by the ´-pre´ suffix. As soon as we have 0.2.0
out, this is hopefully more consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess that the discussion in google/docsy#954 explains why the v
prefix might be needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks sense. Thanks for the explanation ✨
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a related question: how does one normally encode the ID of a Go module? That is, if my Go module m is meant to be at version x.y.z, when in the module's source files would I write / encode the ID? Or is that handled separately?
@LisaFC - And yes, we can do the Netlify build command cleanup through another PR. |
Yes, I think so. |
So @chalin are we ok to merge? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! Do you want to merge or shall I do it?
If you do this one I'll merge the user guide one. |
Done: #167 |
Done 🎉 |
This PR is closely associated PR 801, which tries to bring hugo modules to docsy theme.
The goal is to make use of the example site as easy as possible:
No fiddling around with gut submodules any more.
Please note that this PR is not fully ready for review yet, inside my go.mod, I'm missing the commit hash of the docsy repo once PR 801 is applied. Or I can refer to commit in the branch
modules
(to be newly created in the Docsy repo).