search

PyconUK / pyconuk.github.io

OLD REPOS - DO NOT USE. PyCon UK website
http://www.pyconuk.org/
3 stars 9 forks source link

Jekyll #11

Closed doismellburning closed 9 years ago

doismellburning commented 9 years ago

Because I <3 templating

(YMMV)

ntoll commented 9 years ago

Hi Kristian,

Please add some sort of documentation!!! I've never used Jekyll and have no idea how to use it. A quick howto would be appreciated in the README.

N.

ntoll commented 9 years ago

Also.... Ruby..? Is there something in Python that we can use instead (for static site generation)...?

ntoll commented 9 years ago

In fact, upon thinking about it more, can we please back this out and at least try to find and check a Python alternative..? (I'm not saying NOT Jekyll, but I don't think it's the only choice and I'm uncomfortable that we're a Python community event and we're not dogfooding our language).

ntoll commented 9 years ago

Finally (sorry, it's too early for a Sunday morning), I also <3 templating. ;-)

inglesp commented 9 years ago

+1 to adding some documentation here! It's important that anybody who wants to can build the site locally.

As for which static site generator we use, I can see the appeal of using something written in Python, but I don't think it's a requirement -- and "practicality beats purity"! The advantage of Jekyll is that GitHub knows what to do with a site with Jekyll's structure, so there's no build stage required. As far as I know, this isn't the case for other static site generators.

Thanks @doismellburning for doing the work here.

doismellburning commented 9 years ago

Also.... Ruby..? Is there something in Python that we can use instead (for static site generation)...?

Yes; Pelican + Hyde. Last time I did an evaluation, they were inferior clones of Jekyll; this may not still be the case though.

As @inglesp says though, it'd involve having Travis (or equivalent) do the build, as GH pages won't automatically, plus then either migrating away from GH pages, or having hacks and sadness in Travis to force push the build results to the gh-pages branch. While I'm more than happy to configure this, pay for it, and maintain it, it would seem a suboptimal approach

I'm uncomfortable that we're a Python community event and we're not dogfooding our language

I would prioritise suitability/utility over purity, and look forward to seeing you write Brython ;) </troll>

(Seriously though: sure, but see above for why I wouldn't)

((Yes I did hand-encode those HTML entities above, and yes I did manage to get them the wrong way round at first, sigh))

doismellburning commented 9 years ago

@ntoll See #13 (but, er, also #14 as a test-y-pass-y prereq)

sparkslabs commented 9 years ago

Seems a very bizarre choice to use ruby to drive a python conference website. Seems to suggest that python can't be used for this task, which isn't true. It's not like there aren't static site generators for python. Your site, your rules, but you're less likely to get python people interested in helping out with a ruby powered site.

ntoll commented 9 years ago

So the problem I have is that a fundamental aspect of how the website is built has been arbitrarily decided by a pull request (that was merged quite quickly). Personally, I believe this should have been suggested on the mailing list for all to have a say in - especially since the language of choice is Ruby and not Python.

russel commented 9 years ago

@ntoll @sparkslabs Having chosen to host the site at GitHub pages, the natural choice of system is Jekyll. Whilst it might be nice to use a Python-based system such as Nikola with AsciiDoc (or ReStructured Text), GitHub is a Markdown/HTML/Jekyll/Git workflow. The fact that it is Ruby underneath doesn't actually show and in a sense doesn't matter.

If the site must be driven with Python then GitHub pages is not really the right hosting place. I am not sure where is.

sparkslabs commented 9 years ago

No, github page can be used without using Jekyll. The argument that you must use Jekyll to use github pages is bogus.

At the end of the day though, it's the decision for those willing to put effort in, and I suspect I fall into the camp of "would like to have time but don't" so I'll leave everyone else to it.

Michael.

On 23 March 2015 at 10:59, Russel Winder notifications@github.com wrote:

@ntoll https://github.com/ntoll @sparkslabs https://github.com/sparkslabs Having chosen to host the site at GitHub pages, the natural choice of system is Jekyll. Whilst it might be nice to use a Python-based system such as Nikola with AsciiDoc (or ReStructured Text), GitHub is a Markdown/HTML/Jekyll/Git workflow. The fact that it is Ruby underneath doesn't actually show and in a sense doesn't matter.

If the site must be driven with Python then GitHub pages is not really the right hosting place. I am not sure where is.

Reply to this email directly or view it on GitHub https://github.com/PyconUK/pyconuk.github.io/pull/11#issuecomment-84946129 .

snim2 commented 9 years ago

Deploying Nikola to GitHub:

http://getnikola.com/handbook.html#deploying-to-github

(not an endorsement, I've never used Nikola!)

russel commented 9 years ago

@sparkslabs Indeed GitHub pages can be used without Jekyll, it is that Jekyll is the path of least resistance to getting Markdown-based sources up as a website on GitHub pages.

@snim2 I use Nikola for my website (on advice from Simon Davy, who believes Nikola superior to Pelican) and it works well, I like it. There is this: http://govlab.github.io/6109/posts/static-site-comparison-nikola-vs-pelican.html

Nikola works with AsciiDoc and ReStructuredText as well as Markdown. Indeed my site comprises files using all of them.

Given @ntoll position maybe switch from Jekyll to Nikola even though there is an extra overhead?