I know the shape of the hugo project I’m building. Let’s see which parts I’ll need, repo by repo:
- a config repo - to hold the site settings, and pull in everything via modules.
- base theme - this will be
tule, and I only need it to get started; later I’ll pull in additional theme-y components via modules.
- content - this will potentially many repos, but to start I need a single section:
That’s it! Well, to get started.
Everyone gets a section!
In Hugo a section is a logical division of content, and a lot of info can be inferred from how a section is organized. For this site I want to emulate the idea behind tilde user directories. I’ll have one, and I can put all the maiki-specific stuff into my one repo, and it will live in my section of the site. This one-to-one mapping makes it easy to add more folks to the site, and provides an easily understandable restraint: if you publish information to this site, it will live in this place and in this way.
So I’ll create a repo that is just some text files. I haven’t loaded content via modules yet, so I’m not sure how to best format the file layout. Do I put them all in the root, include
README, and map that to
content/maiki? I think that will work, maybe with a little config tweaking.
tule as a theme
I named my tiny CSS file
tule, so I’d have an easy-to-understand-for-maiki reset that told most browsers to do the thing I care about.
The idea isn’t to create a robust framework that does a bunch of stuff for me. Rather, it captures my “philosophy” of decent defaults for knowledge sharing.
Currently it is:
margin: 0 auto;
padding: 0 2vmin;
I’m still developing exactly what I want this to become. Maybe create my own sense of separation of structure and design… at any rate, it is fine to publish now (it’s what I use on maiki.xyz). But I do need to make it an actual component/theme/module/thing.
A config by any other name
With modules, a “code” hugo repo has gotten kinda weird. It can basically be a single config (I think), which can provide
hugo with enough instruction to pull in data and templating information and deploy a built site. Wow!
I intend to use a media server type computer at my home to deploy the site, and probably have it build once a day or week; I’m in no hurry. That means a cron job on that computer will do three things:
- Pull down any changes to the
hugo, which pulls down everything else and builds the site
- Upload changes to server
Hugo can utilize external apps for certain deployment types, but I don’t know how I’ll upload files at this point.
Next step is to create these repos, one at a time, and discover the many ways to structure home on the web.