ramblinations - pelican

Favicons

Not that modifying the theme base.html is hard, but the process could be easily automated, so it's a good candidate for built-in functionality. Everybody uses favicons. Give Pelican a FAVICON_PATH variable in the configuration, and the engine copies the file to some constant location for themes to pick up and <link>. Easy. (Also, seriously, how awesome is my little boat? I'll tell you: pretty awesome.)

Git integration

Technically this isn't a Pelican item so much as a "make my git hook cooler" item: I want to pull post entry dates from the git commit author date, and tags from the commit message. Seems simple enough, but it gets complicated when you consider the entire change history of an entry. Wheat, a git-based blog engine I tried briefly, handles entry changes by giving the reader literally every change ever made in a clickable list. (With a commit hash and everything, it's pretty wild.) The design makes sense for a wiki-style site, heavy with community content and editorial oversight, but gets a little cumbersome for a personal blog. (I'm ok with readers not seeing every typo I'll ever make, thanks.)

My version would be more boring: Find the commit that added the entry, and use that GIT_AUTHOR_DATE as the initial entry date. It could even find the commit that most recently changed the entry, and add some kind of Updated on foobity bar date footer.

Pulling tags from commit messages could be similarly straightforward: Parse the messages in every commit that changed the entry for whatever the tag pattern is, and add all the tags found. Throw in some kind of lexical mechanism for identifying tags removed (maybe -tag instead of just tag?), and turn the result into a tag list.

Speaking of which

My post-receive now handles multiple branches. Since the Pelican Makefile is part of each branch, publishing a draft is as simple as git checkout draft && make html (or rather, just pushing draft, since the hook takes care of the rest). Along the same lines, incorporating draft changes in the live site is as simple as merging draft to master.

function publish {
    branch=$1

    cd $pelicanweb
    git checkout -fq $branch && git fetch && git reset --hard origin/$branch
    if [ $? -ne 0 ]; then
        echo 'git broke, go check the configs or something'
        exit 1
    fi

    make html && echo "$branch changes live"
}

unset $(git rev-parse --local-env-vars)

while read oldrev newrev ref
do
    branch=`echo $ref |cut -d/ -f3`
    publish $branch
done

One of the things I love about git is how easy it makes website deployment. Stick all your versions (production, development, test, yadda yadda) in different branches, push to a bare repo on the server, and set up your post-receive hook to put the right versions in the right places by checking out individual branches to different working directories. Bam, done.

I would have set up pelican the same way, except I want to be able to make changes directly on the server. Technically, what I should have done is create the bare master repo, point the detached checkout to ...

social