hugo 0.14 #39815
hugo 0.14 #39815
Conversation
|
I presume the new dependencies don't upset |
|
Stable still builds and runs fine for me. I think the extra deps are just ignored. |
|
@BrewTestBot test this please |
|
0.14 just came out—let me just add that to this PR. |
| system "go", "build", "-o", bin/"hugo", "main.go" | ||
|
|
||
| bash_completion.mkpath | ||
| system bin/"hugo", "genautocomplete", "--completionfile=#{bash_completion}/hugo.sh" |
There was a problem hiding this comment.
Should this be in postinstall?
There was a problem hiding this comment.
Unless it's the same for every system/install location: yes.
There was a problem hiding this comment.
For me at least, when it's in post_install Homebrew doesn't automatically link the completion script into /usr/local/etc/bash_completion.d. I have to brew unlink hugo && brew link hugo. Is that expected?
There was a problem hiding this comment.
The user can install the completion script anywhere, but I figure if they're installing hugo with Homebrew it ought to be placed in bash_completion.
There was a problem hiding this comment.
@dunn You probably want to use the bash_completion.install and generate it into the buildpath instead. Can you check if the script contains any hardcoded references to the full path? Thanks!
closes #37083 Closes #37510. Signed-off-by: Misty De Meo <[email protected]>
|
Cool. Should be good to go! |
|
Just FYI. This version of hugo breaks some stuff (path names in my case). I'm not sure why upstream is making such breaking changes (also making slight variable name changes such as .BaseUrl -> .BaseURL ...) but that was a little vexing. I had to revert to 0.13 since I don't intend to touch my content to work around this. As an aside, I can't fathom why 'versions' was removed from brew. |
|
@dylancarlson Can you provide a reproducible test case demonstrating the breakage (and we may roll back)?
It didn't work well and created more problems than it solved. |
|
It is covered here. gohugoio/hugo#1176 We will have to agree to disagree about homebrew/versions :) Maybe I can't see the rationale behind stuffing versions into a separate repo when they are already in the master repo. It's just adding developer overhead and user confusion. 'versions' made sense, IMO |
|
They are already in the master repository but we are unable to fix bugs, security issues and outright errors because they are immutable once they are in the history. Maybe we could just apply https://github.com/spf13/hugo/commit/be7404.patch as a patch? If so, could you try and open a pull request? This should help and I'm happy to walk you through anything else: https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/How-To-Open-a-Homebrew-Pull-Request-(and-get-it-merged).md#how-to-open-a-homebrew-pull-request-and-get-it-merged Thanks! |
|
I'll follow up a bit later and open a new issue in that case since we are getting off-track in this one. I didn't want to clean up .Url -> .URL, .BaseUrl -> .BaseURL (et al) either since I have to do it for themes on multiple sites. Re: master repo, I still disagree. 'versions' was just a convenience feature. I think it would have been better to modify 'versions' with a warning to people using it. Now we're just forcing people to git log, so the only thing being done is making it harder on people who need to revert to an older version in history. Most packages, hugo included, aren't in homebrew-versions and most probably won't be, due to the extra step and effort in maintaining them. There are many varied reasons why users may need to checkout an older commit, and packagers can't account for all those reasons. Having old versions in a separate repo is just bloating the workload in all directions IMO. I used to do a ton of packaging in FreeBSD and Gentoo Linux years ago, I am familiar with what can happen. Maybe this is a philosophical complaint or something. It's trivial to make 'versions' a separate tool, but I'll always see this as an intrinsic feature of the packaging tool. |
The workload for Homebrew maintainers is significantly lower now.
We did. It was ignored.
I don't think using
Thanks. Ideally a PR rather than an issue. |
|
As I say, it might be philosophical. :) If it were me, I wouldn't remove features for the sake of keeping a minority of people from shooting themselves in the feet. Screwing up is part of learning also. I'm not sure homebrew's audience is everyone, as the App Store is for everyone. Doing installs from a terminal implies a certain level of technical competence. |
|
Oh, we don't so much mind people shooting themselves into the foot but we do mind making our own jobs much harder when debugging unrelated issues (which it often did). |
|
Fair enough, thanks for the discussion & for working on homebrew. I have no idea what kind of workload you have. I would imagine Just a thought, if I was in that position, what I might add a 'support' argument to |
Just as a heads-up, If there's a valid use case it's perfectly welcome in Versions. There's stuff in Versions that hasn't been touched in 2+ years and still works on all three "modern" Homebrew-supported OS X versions without patching/etc. It's less prone to breakage than the alternative options. Submitting a formula to Versions that was in the core is as simple as pulling formula from the git history, removing any bottle/head blocks, fixing |
|
@DomT4 thanks. I don't think this formula will come to that. 0.14 was a feature release, hugo releases every 3-4 months so we should see this fixed in the next by ~September. If other people complain about this issue, I'll be happy to do a PR. For now I've rolled back to 0.13 and pinned it. |
The new dependencies are only needed for HEAD currently but they'll also be needed in the next stable release.