Rust moving fast, an important things to know about a Rust project on github is "will it build" before bothering git cloning it

Remove the usage of unstable features so cobalt can be used with rust stable.

Maybe using log or something even more sophisticated.

Consider following folder structure:

* path/to/repo/
  * index.tpl
  * _layouts/
    * default.tpl
    * posts.tpl
  * _posts/
    * 2014-08-24-my-first-blogpost.tpl
  * assets/
    * stylesheets/
      * style.css
    * javascripts/
      * script.js

Cobalt should copy the assets folder into the generated _build folder so pointing your apache/nginx vhost towards _build folder should serve the assets properly.

Currently in https://github.com/cobalt-org/cobalt.rs/blob/master/src/main.rs#L26 the defaults for some configuration options are hardcoded.

We should use the defaults from https://github.com/cobalt-org/cobalt.rs/blob/master/src/config.rs#L22 so we have 1 place where we change defaults.

We should not expect/unwrap everything that could possibly go wrong, error handling in Rust can actually be done very nicely. For each of these cases, we need to decide:

1. Can we emit a warning and continue?
2. Should we return a CobaltErr because we can't continue here

Where one can specify the port to serve on

Per default _layouts/ is used for layout files. When trying to configure this through the command line flags or the config file it is not working properly:

benny@benny-Lenovo-Y50-70:~/Dev/other/tak1n.github.io$ cobalt build --source /home/benny/Dev/other/tak1n.github.io/src/ --destination /home/benny/Dev/other/blog --layouts layouts --trace
[info]   Building from /home/benny/Dev/other/tak1n.github.io/src/ into /home/benny/Dev/other/blog
[trace]  Build configuration: Config { source: "/home/benny/Dev/other/tak1n.github.io/src/", dest: "/home/benny/Dev/other/blog", layouts: "layouts", posts: "_posts", template_extensions: ["tpl", "md", "liquid"], rss: None, name: None, description: None, link: None }
[debug]  Layouts directory: "/home/benny/Dev/other/tak1n.github.io/src/layouts"
[debug]  Posts directory: "/home/benny/Dev/other/tak1n.github.io/src/_posts"
[trace]  Generating learning.html
[trace]  Generating index.html
[trace]  Generating technology.html
[trace]  Generating _layouts/default.html
[info]   Created /home/benny/Dev/other/blog/index.html
[info]   Created /home/benny/Dev/other/blog/learning.html
[info]   Created /home/benny/Dev/other/blog/technology.html
[error]  error: No extends property in default
[error]  Build not successful

It is somehow treating the liquid template in layouts/ as non layout file in which you need a extend statement.

When typing cobalt --help at the command line, the newly added serve command does not appear in the help text. It would be nice to mention its existence and to describe its optional switches, if it has any.

It would be nice to be able to have permalinks similar to what jekyll does.

I think it could be a good idea to not require the .tpl extension. It will improve the Jekyll compatibility and it will be possible to reuse Jekyll themes, what could be a great pro for users starting using Cobalt.rs

The integration tests in the tests folder currently write to the tmp directory in the same folder. That's not really elegant. We could rather use tempdir to write them to a temporary directory.

https://github.com/frewsxcv/rust-rss

Having tons of similarities to Jekyll (Liquid templates, front matter, YAML), it would be a waste not to maintain backwards compatibility. This issue is intended to track other issues that ensure we get compatible.

We should enable people to run a local website server with a command like cobalt serve or cobalt server or cobalt start

In the index layout following should be possible:

{% for document in documents %}
   <a href="{{ document.href }}" title="{{ document.name }}">{{ document.name }}</a>
{% endfor %}

Note this is pseudo code, not sure if for looping is possible in mustache templates.

Note: I posted this first on the johannhof/markdown.rs#13. Not sure whether the bug is in cobalt or in the Markdown library, so reposting here.

The error message reported by the panic, when looked up on Google, led me to this Rust book page on string slicing. Could you please look into this? This is a pretty major bug. Thanks!

Update: I'm using cobalt 0.2.0 with markdown 0.1.1 on rustc 1.9.0-nightly (eabfc160f) on 64-bit Arch Linux.

Output

[info]   Building from blog into web
[info]   Created web/index.html
[info]   Created web/_posts/week0.html
thread '<unnamed>' panicked at 'index 42 and/or 43 in `strictly read-only operations, so they don’t fit into either *views* or` do not lie on character boundary', ../src/libcore/str/mod.rs:1670
note: Run with `RUST_BACKTRACE=1` for a backtrace.
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Any', ../src/libcore/result.rs:746
[info]   Created web/_posts/week6.html

Backtrace

stack backtrace:
   1:     0x55b8389646c0 - sys::backtrace::tracing::imp::write::h3e252ef592ef6f37cHv
   2:     0x55b83896757b - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44999
   3:     0x55b8389671e8 - panicking::default_handler::h5a98c984225a759d1nA
   4:     0x55b838958bbc - sys_common::unwind::begin_unwind_inner::ha2071187f9cf0076vvu
   5:     0x55b838959008 - sys_common::unwind::begin_unwind_fmt::h65e28ed738ec1ab9Buu
   6:     0x55b838963b31 - rust_begin_unwind
   7:     0x55b83899e48f - panicking::panic_fmt::h98dcb863ad76e04b7mM
   8:     0x55b8389a5584 - str::slice_error_fail::h98e1db52ab0be957SIT
   9:     0x55b83890bbed - parser::span::parse_spans::hd76b1aa268612ed8qja
  10:     0x55b838907404 - parser::block::parse_blocks::h40207e955dc8e399kza
  11:     0x55b838902e54 - to_html::h178a80c20d1918a2kcb
  12:     0x55b8388ac73a - F.FnBox::call_box::h9582497645605739343
  13:     0x55b8388ae384 - sys_common::unwind::try::try_fn::h11935924224408508601
  14:     0x55b838963abb - __rust_try
  15:     0x55b8389616fd - sys_common::unwind::inner_try::h4a24c2847e3d9a74xsu
  16:     0x55b8388ae52a - boxed::F.FnBox<A>::call_box::h9605662001311154786
  17:     0x55b8389660f9 - sys::thread::Thread::new::thread_start::h486bc7814d54d94ellz
  18:     0x7fc45768f423 - start_thread
  19:     0x7fc4571b8cbc - clone
  20:                0x0 - <unknown>
thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Any', ../src/libcore/result.rs:746
stack backtrace:
   1:     0x55b8389646c0 - sys::backtrace::tracing::imp::write::h3e252ef592ef6f37cHv
   2:     0x55b83896757b - panicking::default_handler::_$u7b$$u7b$closure$u7d$$u7d$::closure.44999
   3:     0x55b8389671e8 - panicking::default_handler::h5a98c984225a759d1nA
   4:     0x55b838958bbc - sys_common::unwind::begin_unwind_inner::ha2071187f9cf0076vvu
   5:     0x55b838959008 - sys_common::unwind::begin_unwind_fmt::h65e28ed738ec1ab9Buu
   6:     0x55b838963b31 - rust_begin_unwind
   7:     0x55b83899e48f - panicking::panic_fmt::h98dcb863ad76e04b7mM
   8:     0x55b8388fd08a - result::unwrap_failed::h15670906751293521885
   9:     0x55b8388fce35 - scoped::JoinState::join::h13c7fea341a406c773a
  10:     0x55b8388ae938 - F.FnBox::call_box::h14351671975044799388
  11:     0x55b8388fd30b - scoped::Scope<'a>::drop_all::h06cdcd63e6265a66u5a
  12:     0x55b8388a3a82 - cobalt::build::he1a9e9c26970c869Uaa
  13:     0x55b838894e40 - main::h2e962ad0501d7c94Raa
  14:     0x55b838966e44 - sys_common::unwind::try::try_fn::h5354436054083437191
  15:     0x55b838963abb - __rust_try
  16:     0x55b8389668db - rt::lang_start::h673f33b817ea5ba77fA
  17:     0x7fc4570f170f - __libc_start_main
  18:     0x55b838891da8 - _start
  19:                0x0 - <unknown>

It would be useful to have the output path (relative to the final destination) of a certain file for usage when rendering that file or when listing e.g. blog posts. In my own blog I currently have to do this:

title:   Using rustfmt in Vim
date:    03 Nov 2015 23:00:00 +0100
path:    rustfmt-vim.html

Not very nice.

We should handle relative paths better. @tak1n suggested that we use the build dir to be the base of the relative path. I think this would be good and allow us to pass that value to liquid-rust so that the template paths do not need to be very long.

Example:
@tak1n
cobalt build -s src/ -d /wherever/I/want -c .my_config.yml
It should respect the source directory and search for the config file in src/
currently as far as I know you have to do following
cobalt build -s src/ -d /what/what -c src/.my_config.yml

~/D/r/c/cobalt.rs ❯❯❯ rustc --version                                                                                                                                                                                                       ⏎
rustc 1.4.0 (8ab8581f6 2015-10-27)
~/D/r/c/cobalt.rs ❯❯❯ cargo --version
cargo 0.5.0-nightly (833b947 2015-09-13)
~/D/r/c/cobalt.rs ❯❯❯ cargo test
     Running target/debug/cobalt-6167f0d79539a620

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/cobalt-c44e4fc9cd2c2b10

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/mod-75ffe4cf35f0cc13

running 4 tests
Created tests/tmp/no_extends_error/index.html
test no_extends_error ... ok
Created tests/tmp/dotfiles/index.html
Created tests/tmp/example/index.html
Created tests/tmp/liquid_error/_posts/2014-08-24-my-first-blogpost.html
test liquid_error ... ok
Created tests/tmp/example/_posts/2014-08-24-my-first-blogpost.html
test example ... ok
Created tests/tmp/dotfiles/_posts/2014-08-24-my-first-blogpost.html
test dotfiles ... ok

test result: ok. 4 passed; 0 failed; 0 ignored; 0 measured

   Doc-tests cobalt

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

~/D/r/c/cobalt.rs ❯❯❯ cargo test
     Running target/debug/cobalt-6167f0d79539a620

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/cobalt-c44e4fc9cd2c2b10

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

     Running target/debug/mod-75ffe4cf35f0cc13

running 4 tests
Created tests/tmp/example/index.html
test example ... FAILED
Created tests/tmp/no_extends_error/index.html
test no_extends_error ... ok
Created tests/tmp/dotfiles/index.html
Created tests/tmp/liquid_error/_posts/2014-08-24-my-first-blogpost.html
test liquid_error ... ok
Created tests/tmp/dotfiles/_posts/2014-08-24-my-first-blogpost.html
test dotfiles ... ok

failures:

---- example stdout ----
        thread 'example' panicked at 'assertion failed: run_test("example").is_ok()', tests/mod.rs:46



failures:
    example

test result: FAILED. 3 passed; 1 failed; 0 ignored; 0 measured

I'm just getting started again with rust, as I was pretty inactive the last months I just tried to build cobalt under rust 1.4.0 stable and cargo 0.5.0
Building was fine but when running the tests they randomly fail and pass, have to dig up whats the cause of it.

Reply to this issue with what license you'd like, and I'll attempt to contact everyone on https://github.com/cobalt-org/cobalt.rs/graphs/contributors to make sure they're ok with it, then PR the license files and cargo.toml license line.

Cobalt should provide a basic command for creating a new project with config file and everything setup.

cobalt new MyBlog

It would be cool to have a cobalt.yml or cobalt.toml (maybe yml is easier because our front-matter is yaml already) to set all options that can currently only be passed through the command line.

Right now every time you change a file it rebuilds the whole site. We may want to do a few things:

• Refactor cobalt.rs so that the builds can be done incrementally.
• Add delay for watcher so that we do not need to do as many builds
• Clean up watch command of all unwraps

If there is anything else let me know! 😄

The RSS spec defines a lot of optional fields that we do not support right now. We should accept more arguments through both the config file (for page-wide fields) and in the article front-matter (for article fields).

See http://cyber.law.harvard.edu/rss/rss.html

#56 and #49 got me thinking, we should enable support for all different kinds of pre-processors, such as Markdown, and maybe even transform things like RSS into plugins.

I'd like the system to be flexible AND easy to use, which is not so trivial for a statically compiled tool like Cobalt. One interesting way could be to use cargo feature flags and let the user specify the desired features on install.

This way we could even split up preprocessors into different crates and keep the main code base clean.

https://github.com/chyh1990/yaml-rust?

I think we should start adding detailed info on the wiki. This issue is to keep track of our progress.

The wiki should contain:

• CLI usage
• Config setup
• Avaliable tags and how to use them.
• Avaliable variables and how to use them. Example: list what variables are available to use in an if block.

If there are any other let me know and I will add it to the list.

Would it be possible to have the ability to recursively extend layouts? It would help out a lot if you wanted to having some navigation bar on all your pages, but then extend that navigation bar with another template.

Maybe this is a bit over the top but creating the actual document sounds like something that can be easily made parallel. We already have parsed all information and there should be no need for any mutable shared state when creating.

Eventually we could even think about parallelizing the parsing stage

Have you thought about integrating Clippy into the project to normalize the coding style?

I just tried it out on my fork and it found a bunch of things that could be corrected. I would be open to working through them and getting it integrated if you like the idea.

Hi,

I'm currently moving my homepage from jekyll to cobalt.rs and I love it! Thanks for this tool. 😃

One thing that I'm missing is code highlighting. While I could use external javascript highlighters it would be nice to have a pure html/css solution.

Jekyll supports code snippet highlighting as a filter: http://jekyllrb.com/docs/templates/#code-snippet-highlighting. Maybe something like this can also be possible in cobalt.rs? Thinking a bit outside the box it would be nice to have a simple plugin system for things like that.
I've actually written a super simple wrapper around pygments that I try to use for syntax highlighting.
(See https://github.com/mre/pygments-rs)

Do you think something like this might make sense?

It's obviously not a huge issue but it is a bit inconvenient.

Can be reproduced from a clean working directory by:

$ ls -A
$ cobalt -v
0.2.0
$ cat > .cobalt.yml
source: src
dest: public
$ mkdir src
$ cat > src/index.html
<!DOCTYPE html>
<html>
<body>
<h1>some title</h1>
</body>
</html>
$ cobalt build
[info]   Using config file ./.cobalt.yml
[info]   Building from src into public
[info]   Copying remaining assets
[error]  error: Could not copy "src/index.html"
[error]  Build not successful
$ mkdir public
$ cobalt build
[info]   Using config file ./.cobalt.yml
[info]   Building from src into public
[info]   Copying remaining assets
[info]   Build successful

It would be cool to be able to output the time it took to build a single file and the whole project.

If you use the watch command in the same directory that you build to then it will recursively call itself forever.

After #3 is resolved and proper testing was added refactor "bad" code out.

See #31, this would be actually be quite easy to implement.

We need to

• add an additional option flag in main.rs
• pass that to cobalt::build
• in cobalt::build extend the walkdir filter with a check for the filename

It seems that pages generated and placed in the _posts folder on Windows systems running the MSYS2 toolchain are linked to using \ instead of /.

See this example website by @Aceeri. As of 2016-03-21, the link to This Week in Amethyst 6 is generated as:

http://aceeri.github.io/_posts\week6.html

when it should be:

http://aceeri.github.io/_posts/week6.html

e138ef8

It's after May 15th.

Probably descending, e.g. newest first.

Since rust reach 1.0, should we able to build under 1.0? Now it reports

this feature may not be used in the stable release channel

Learn testing with rust and add:

• Unit tests
• Integration tests

So having all my posts in _posts is nice but what if I'd like them to be in blog? Also, what if I want to generate an about.html?

Maybe we should take a more generic approach of compiling all .tpl files, no matter where they are (or, better, allow the user to specify the file ending template files should have).

Could you specify the toolchain you did the last successful build (and add it to rustle command in Readme.md)?

Currently when having posts as markdown the generated output still has it in markdown format and file.
Check why .md files are not processed properly.

It would be cool if Cobalt could watch the build directory for changes and rebuild if the --watch flag is passed.

If I don't delete *.swp before running cobalt build, it sometimes dies saying there is invalid UTF-8 in a file. Probably, it should either skip non-UTF-8 files (and emit a warning), or know how to skip common editor swap files.

Get cobalt.rs to compile on rust 1.0.0.alpha.2
See https://travis-ci.org/cobalt-org/cobalt.rs/jobs/54463125

Currently the documentation written in the README is a little bit messy and incomplete.
I've started to create a github page at https://github.com/cobalt-org/website.

We probably can use cobalt to create this site 😄

The site should basically contain following:

• high level usage examples
• detailed examples for cli, config etc etc
• detailed rustdoc for public accessible traits etc (rustdoc?) if existent

The third point is kinda optional, because cobalt is a binary and not a lib.

But if some of the lib stuff we use for the executable is public accessible (extern create cobalt, use cobalt::Whatever) we should have good documentation for this public api.

I think this only supports plain-text for now, but if it supports rST or Markdown it should be explicitly noted in the README.