Build related 0.43 tasks

[bep]

• Update Goreleaser with a new set of binaries for Win, MacOs and Linux (for now)
• Finish the Docker image for the above
• Snap? I assume we leave it as is for now. @anthonyfok
• Talk to the Brew people.

[anthonyfok]

Snap? I assume we leave it as is for now. @anthonyfok

I have just started tweaking snapcraft.yaml and experimenting with the extended-snap branch, which https://launchpad.net/~gohugoio/+snap/hugo-dev is now temporarily tracking and making test builds for me. :-)

[bep]

Re. snap, is it possible to deliver 2 versions? I assume there will be people wanting a "pure Go" Hugo version and does not need the SCSS/SASS.

[anthonyfok]

Re. snap, is it possible to deliver 2 versions? I assume there will be people wanting a "pure Go" Hugo version and does not need the SCSS/SASS.

I think it is possible. Would you like two separate executables in the same snap (easier to do), or two entirely separate snaps?

Assuming the first case, how would you like to name the executables? How about hugo and hugo.unextended?

[bep]

hugo and hugo.unextended?

... Unextended?

No, I was more thinking some "snap target" (I'm not sure what that is) ... like dev, extended.

If two binaries, then the default should be the one without change, ie. hugo and then hugo-extended.

But I'm thinking out loud here.

[bep]

Note that the binaries on the release page will be named "hugo" and "hugo_extended"; I think I want them to be named the same, but that will have to wait.

[anthonyfok]

No, I was more thinking some "snap target" (I'm not sure what that is) ... like dev, extended.

Snaps can be released into 4 channels, namely "stable", "candidate", "beta" and "edge". IIRC, hugo-dev is just a random name I picked for the build daemon (?) that tracks the hugo master branch for the most cutting-edge builds, and have them uploaded and published directly into the "edge" channel, but the name hugo-dev itself doesn't actually appear anywhere in the snap itself, and snap has no knowledge of that name.

So, to install what I named hugo-dev on Launchpad, the end user would actually use snap install hugo --edge, and not snap install hugo-dev.

While we can create an entirely new snap called hugo-extended, that seems a bit too complicated to me, especially we would have to maintain an extra branch with a special snapcraft.yaml that says name: hugo-extended on its the first line.

At least that is my (limited) understanding of it.

If two binaries, then the default should be the one without change, ie. hugo and then hugo-extended.

Since most end users do not compile Hugo from source and instead use whatever release binaries are provided to them, I and since Hugo with SCSS support is such a hot feature, I actually think that most people would prefer using the full Hugo (with extended build tag) and wouldn't worry too much about the enbedded C LibSass. (i.e. most Hugo users do love Go but are not Go purists, or most likely don't even know how to write in Go code.)

For me, with my "end user" hat on, I would rather prefer having one single binary but with a runtime flag to disable the SCSS feature if I were to keep using gulp or something else to build my SCSS files.

But that's just me and my guess. I could be wrong. ;-)

Note that the binaries on the release page will be named "hugo" and "hugo_extended"; I think I want them to be named the same, but that will have to wait.

Is that due to Gorelease not yet being ready for them to be named the same? Or for some other reasons?

[anthonyfok]

Is that due to Gorelease not yet being ready for them to be named the same? Or for some other reasons?

I should have looked more carefully. You've already opened #4916. ;-)

[bep]

I spent 8 hours yesterday to get Windows and Darwin builds from a Docker container, and today has also been a whole lot of other troubles, so I think I will postpone the Snap discussion.

[vsopvsop]

Instead of hugo-extended can it be named just hugo+

Hugo Vs. Hugo-plus benchmark

[caarlos0]

About snaps: goreleaser can generate them as well, but it doesn't publish them for now... (there is an issue for that)

Once goreleaser can also publish, it would be straightforward to have 2 snaps IMHO...

[anthonyfok]

I spent 8 hours yesterday to get Windows and Darwin builds from a Docker container, and today has also been a whole lot of other troubles, so I think I will postpone the Snap discussion.

I didn't quite realize the full complexity of the using-Docker-for-Windows-and-Darwin-builds when I first read your tweet, but after seeing what you wrote above, and starting to think about it... Wow, huge task indeed! You are amazing as always!

Meanwhile, the Snap build with two binaries is a lot more trivial and seems to be working. I'll make more tweeks and try to match the names hugo and hugo_extended as much as possible.

---

several hours later

---

Changes to snapcraft.yaml pushed to master in commit e1027c5.

Due to snap's design (to avoid namespace collision), hugo.extended can be readily made accessible but not hugo_extended. The latter will hopefully be available in a week or two, see the "automatic alias" request at https://forum.snapcraft.io/t/hugo-auto-alias-request-for-hugo-extended-hugo-extended/6297

[bep]

@anthonyfok not sure I understand; In the main release we package it in several archives (one extended, one not), but with the same binary. A user wants one of them, not both. So we don't need (want?) different binary names, that would lead to confusion. Does the user have to typo "hugo_extended ...?"

[anthonyfok]

@anthonyfok not sure I understand; In the main release we package it in several archives (one extended, one not), but with the same binary. A user wants one of them, not both. So we don't need (want?) different binary names, that would lead to confusion.

Does the user have to type "hugo_extended ...?"

Yes, with the current snapcraft.yaml that I just committed.

So, would you prefer that Hugo snap users use snap install hugo to install the pure-Go version, and use snap install hugo-extended to install the "extended" version, and in either case, the end users simply run hugo?

If that is the case, I think we'll need to have a separate snapcraft.yaml with the first line name: hugo changed to name: hugo-extended, and probably have that "extended" snapcraft.yaml live on another branch, say "master-extended-snap", and maybe "stable-extended-snap", and probably have these branches automatically rebased and updated from "master" and "stable" with some kind of automated git hook. I could go and set up a new snap called "hugo-extended" now on the snapcraft dashboard web interface and pursue that route.

[anthonyfok]

Good call in reverting the multi-binary snapcraft.yaml! hugo.extended or hugo_extended is confusing to the end user, not to mention that the bash completion does not work with hugo_extended. ;-)

I went ahead and began a new experimental snap named hugo-extended built from master-extended-snap extended-snap-master intended for the "edge" channel. It is currently building at:

• https://code.launchpad.net/~gohugo.io/+snap/hugo-extended-dev

And should eventually show up at:

• https://dashboard.snapcraft.io/snaps/hugo-extended/

For the time being, the wrapper executable is called /snap/bin/hugo-extended 😛 unless the end-user set up an alias with

snap alias hugo-extended hugo

or until 7-day voting period after we file a request for "automatic alias" that is managed at the Snap store:

• https://forum.snapcraft.io/t/auto-alias-request-for-hugo-extended-hugo/6297

I think we can wait a week or two until all these are sorted out before asking a few volunteers to test and give feedback. :-)

[bep]

I'm into all sorts of "does not work" on CircleCI, which is my third day in a row with nothing but trouble ... I think this is a sign from above that I need a vacation ...

[anthonyfok]

Hang in there! Getting these CI things are very tricky indeed, not to mention such a complicated cross-platform setup with Docker! You are our fearless leader! We have full trust in you!

(If you wish, I'd be more than happy to help, though admittedly my experience with Circle CI and Docker are minimal.)

[bep]

The CircleCI thing was my fault; I had slipped with some Git resets... I'm getting there...

[klakegg]

Is the extended edition supposed to be a permanent solution? We're talking 2 MB extra, so I can't at the moment see the benefit of having two editions.

Do you see other features becoming exclusive to the extended edition in the future?

[anthonyfok]

Just a final comment on this issue related to our Snap setup for the "extended" build of Hugo:

The Snapcraft experts recommend the use of tracks to us, which was unbeknownst to me. (/me embarrassed):

@chipaca (John Lenton) wrote:

hmm, reading that issue, wouldn’t it make more sense to have a single hugo snap, with an extended track ?

@roadmr (Daniel Manrique) wrote:

Hi,

In principle this seems to fit the use case for tracks:

snap install hugo <- non-libSass version
snap install hugo --channel=extended  <- libSass version

Just be aware that you will need to publish the corresponding binaries to the matching track, otherwise > people tracking extended will not receive updates.

Also, each track has its own independent set of risks (stable, candidate, beta, edge), so this also works:

snap install hugo --channel=extended/beta

I’m +1 to giving a track for Hugo to maintain this extended version “in parallel” with the traditional one.

Per the process, there’s a voting period, at the end of which we’ll look at the votes from reviewers (mine included) and act on the track request. Thanks for your patience!

• Daniel

I think this is also something that @bep has in his mind in the first place. And, indeed, the Skype Snap is also using the track feature for its "insider" build. No need for "two executables" or a separately named hugo-extended snap complexity.

As of today (2018-07-09), we are into the 3-day (or 7-day?) review/voting period for the creation of an extended track for the existing hugo snap.

I'll be tracking this personally over the next few days, and will build the snaps for both the default track and the "extended" track when it is ready.

[caarlos0]

About snaps: goreleaser can generate them as well, but it doesn't publish them for now... (there is an issue for that)

Once goreleaser can also publish, it would be straightforward to have 2 snaps IMHO...

FWIW, GoReleaser can now publish snaps: https://carlosbecker.com/posts/goreleaser-snap-travis/

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.