Tut-powered blog

[larsrh]

Usage

1. Put a blog post into posts instead of _posts.

2. Add the following front matter:

   tut:
     scala: 2.11.8
     binaryScala: "2.11"
     dependencies:
       - org.typelevel::cats-core:0.7.2
   

3. sbt run

4. This will process the posts/*.md files into _posts.

Todo

• unyolo error handling
• make Travis execute sbt run
• make Travis check that there are no dirty files
• ... or let Travis deploy it in the first place?

[larsrh]

Review by @tpolecat who should prepare himself with his bucket first. I have a suspicion that my code is too sloppy for him.

[adelbertc]

Hm is there a reason why you removed the book modifier?

[larsrh]

Did I? I have no idea what that modifier does.

On 3 October 2016 20:46:38 CEST, Adelbert Chang notifications@github.com wrote:

Hm is there a reason why you removed the book modifier?

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#119 (comment)

[adelbertc]

Oh right because you only have the compiled file. I'll PR against your branch the original tut file I have.

EDIT Here you go: https://github.com/larsrh/typelevel.github.com/pull/1

[tpolecat]

This looks good to me. I wonder if it should just be folded into tut. It's a distinct use-case but not uncommon, it turns out. Maybe see how it works out here first.

As an optimization I think you can safely do up-to-date checks on output files since your dependencies are all binaries.

[larsrh]

This looks good to me. I wonder if it should just be folded into tut. It's a distinct use-case but not uncommon, it turns out.

There are two possible approaches for folding it into tut:

• Don't use coursier to download an appropriate tut version, just use depend on tut-core directly. Advantage: Less classloading magic. Disadvantage: You'd need to support all sorts of Scala versions into eternity.
• Use coursier to download an appropriate tut version. Advantage: Easier cross-Scala support over time. Disadvantage (?): Code inside tut which doesn't depend on anything else in there.

Maybe see how it works out here first.

Sounds like a good idea.

As an optimization I think you can safely do up-to-date checks on output files since your dependencies are all binaries.

Could you explain that? I don't understand what that means.

[adelbertc]

Do we expect the compiled (from tut) code to be part of commits? For instance the tut file changed after https://github.com/larsrh/typelevel.github.com/pull/1 but the corresponding post does not reflect that (there should be no difference between what's currently in master and what is generated from the tut I PR'd).

[larsrh]

Yes, that's the expectation in the current setup.

[adelbertc]

Hm I wonder if it's possible to do this through CI. Not sure how that would work though since the file would be created as part of the CI process and then somehow added to the commit.

On a related note, this file needs to be re-generated then since it's not the same if you generate from what the tut file is now.

[larsrh]

One possibility is to:

1. move all posts to the _tut directory
2. add _posts to .gitignore
3. copy non-tut files from _tut to _posts
4. process tut files from _tut to _posts
5. let Travis commit the results in the gh-pages branch

[tpolecat]

As an optimization I think you can safely do up-to-date checks on output files since your dependencies are all binaries.

Could you explain that? I don't understand what that means.

What I mean is, if the output file exists and is newer than the source file, there's no point running tut. Might be worth it to check since running tut this way is expensive.

(Normally tut can't do this because the tut documents depend on project sources that may have changed even if the tut input doc didn't.)

[larsrh]

Got it.

[larsrh]

@tpolecat I've implemented your optimization. I'm now implementing automatic deployment.