Live data from Hacker News

Introducing Lektor – A Static File Content Management System For Python

lucumr.pocoo.org

21–30 of 94 posts

Re: Introducing Lektor – A Static File Content Management System For Python

#21
post #19

Direct links to project: * Website: https://www.getlektor.com/ * Github: https://github.com/lektor/lektor Would be really curious to hear how people like it :)

You need to make sure you have the following software installed on your computer: - Python 2.7 (not Python 3.x) I've read some of your remarks about Python 3, but it seemed like you were (at least begrudgingly) accepting the shift to Python 3. So why no forwards compatibility here? Any plans to support Python 3 in the future?

I build this originally for myself and i don't use python 3. I'm happy to accept patches for python 3. I think it should not be hard.

Re: Introducing Lektor – A Static File Content Management System For Python

#22

Direct links to project: * Website: https://www.getlektor.com/ * Github: https://github.com/lektor/lektor Would be really curious to hear how people like it :)

Looks nice, Armin

A question (that will surely become a FAQ) - how does this compare with Pelican? Is this a non-programmer-friendlier alternative to Pelican?

Re: Introducing Lektor – A Static File Content Management System For Python

#24
This looks great! The native desktop app is a powerful way to drive adoption with non-technical people.

Cactus was on the right track with that although I'm fairly sure the author, Koen Bok is now focussed on his company, Framer. Are there plans to build clients for other platforms? I guess the community can jump in at any time.

Sidenote: do people know of native clients for the other major static site generators like Jekyll, Hugo, Middleman?

Shameless plug: If you're looking for somewhere to host your static site, please check out my side project, http://www.knownly.net

Re: Introducing Lektor – A Static File Content Management System For Python

#25
post #7

Earlier quoted context omitted.

the ini-file configuration seems a bit strange to me(esp since it seems to be ini-files that occasionally contain python code). Why did you go with them instead of making these python classes? To allow the GUI to edit parts of them as well?

> the ini-file configuration seems a bit strange to me(esp since it seems to be ini-files that occasionally contain python code). Why did you go with them instead of making these python classes? To allow the GUI to edit parts of them as well? I grew to heavily dislike the idea of just executing random code to configure things. Impossible to expose to tools, even harder to reason about it. Note that these files do not…

[deleted]

Re: Introducing Lektor – A Static File Content Management System For Python

#26
From the original post:

> There is very little innovation in that space and that's a bit unfortunate

I'll have to respectfully disagree with Armin here, but perhaps I map the terrain a little differently than he does.

In addition to the half-dozen tools he names, which are more narrowly targeted at blog-like static sites, the broader space of asset pipelines and static generation is seeing a lot of innovation. I'd point to Gulp and Rails' latest as a sign that there's more work to do here. Even strictly in the Django world, there are a zillion asset-pipeline-like-apps; django-compressor and django-pipeline, the two most used, are quite different in their approach and philosophy.

I'm excited by this proliferation of tools for generating static web content "offline" and expect to see far more in the future. Lektor looks like another interesting piece to the puzzle, particularly in its focus on end-users rather than programmers. (Anyone remember Movable Type? That's probably the first user-centric static site generator to gain widespread use?)

Re: Introducing Lektor – A Static File Content Management System For Python

#28
post #7

Earlier quoted context omitted.

the ini-file configuration seems a bit strange to me(esp since it seems to be ini-files that occasionally contain python code). Why did you go with them instead of making these python classes? To allow the GUI to edit parts of them as well?

> the ini-file configuration seems a bit strange to me(esp since it seems to be ini-files that occasionally contain python code). Why did you go with them instead of making these python classes? To allow the GUI to edit parts of them as well? I grew to heavily dislike the idea of just executing random code to configure things. Impossible to expose to tools, even harder to reason about it. Note that these files do not…

>Lastly the reason ini over yaml is purely that this can preserve comments and doing the same for yaml is a lot more work i did not have time for :)

Was that the only thing that bothered you about YAML/pyyaml or were there other things you'd like to see fixed?

Re: Introducing Lektor – A Static File Content Management System For Python

#30
post #22

Direct links to project: * Website: https://www.getlektor.com/ * Github: https://github.com/lektor/lektor Would be really curious to hear how people like it :)

Looks nice, Armin A question (that will surely become a FAQ) - how does this compare with Pelican? Is this a non-programmer-friendlier alternative to Pelican?

It is. But it also is a lot more flexible. It's more of a framework than a simple generator.
Post reply on HN