Theme components listing?

Meta
1

Now that we have the ability to compose themes with 0.42, will theme components (as in those not meant as stand-alone themes) have their own listing separate from ‘full’ themes? (Or does one already exist?)

Thanks for the feature BTW!

2

We have to improve in this area. What and when is a little in the blue. We are a little short-staffed …

I wrote about this before, but to get the real power of themes and theme components, we need to get some kind of dependency manager up and running. Currently the script that builds the Hugo themes site does not support themes that themselves defines theme components inside config.toml.

The goal is that you (alternatively) could write:

theme = ["https://github.com/kaushalmodi/shortcode-collection", "https://github.com/kaushalmodi/bep/cool-theme"]

(note, I have not thought about the syntax above, it could also make sense to have this in its own file).

And Hugo would resolve those dependencies transitive for you. If you add versoining to the above it becomes hard, but in its simplest form it should not be too hard.

3

While we are brainstorming this, your above dummy theme variable means that Hugo will do the git clone. Then adding version is just a git checkout operation after the clone, right?

Then maybe the theme string elements can be “REPO_URL@BRANCH” or “REPO_URL@TAG”.

If it’s already cloned, would Hugo also do the pull? I think doing a pull makes sense. Though, need to think of the cases where user modified the cloned repo, and pull doesn’t result in a clean merge. Hugo might need to raise a warning there, that the pull of X theme wasn’t possible.

For now, this seems to be the only way… manually clone the theme components and commit them as submodules so that the theme exampleSites can build: https://github.com/kaushalmodi/hugo-bare-min-theme/tree/master/exampleSite/themes.

4

I suspect we would mimic parts of the behaviour of

GitHub - golang/vgo: [mirror] Versioned Go Prototype (which is going into go in Go 1.11 I think).

So (just thinking out loud):

  • hugo get -u will get and update all dependencies (themes and theme components). These will be cached somewhere. I think we could support other remotes than Git, but that would be required for any versioning, I guess.
  • The plain hugo command will probably also do a dependency check and update if needed …

But as you point out, we could probably make it simpler in the version department (there are whole lots of discussions about this in the Go world) …

But if you use git revisions as part of the URL scheme (“REPO_URL@BRANCH"), we could probably say that if the project has repo1@v1.1 and one of the themes has repo1@v1.2 – we would pick the project version …

Else we need to add semantic versioning and pick the “lowest version” needed to get it to work.

Whatever we do, the rules should be really simple …

Also, it should be possible to “vendor” your dependencies (i.e. commit them to Git so you don’t have to resolve these dependencies on every build – and to get reproducable builds).

5

This is simple. Just use topic in GitHub like hugo-theme. So start tagging components hugo-theme-component for automatic listing here: hugo-theme-component · GitHub Topics · GitHub. Later if bep and team decide to start blessing certain components the way themes are they could pull straight from the GitHub API by topic and whitelist those which’ve passed a code review or security audit.

2 Likes
6

Great idea! I have started doing that.

2 Likes
7

I haven’t seen anything more recent than this about automating a gallery for Theme components, is this still the current state?

Just looking for the proper way to set up a component/theme to share that won’t work well with the basic example.

Does seem challenging to automate something for seemingly unlimited types of components.