Static Site Generators with Justin Mayer and Roberto Alsina

Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great.

You can follow us on Itunes, Stitcher, or TuneIn Radio,

and you can contact us by giving us feedback on iTunes.

Contact us on Twitter. We're at podcastdouble

underscoreinit.

You can email us at host@podcastinit.com

or leave comments on our show notes. And we also recently added a Google plus page at plus podcast init the Python podcast.

We donate our time to you because we love Python and its community.

If you would like to return the favor, you can send us a donation with details on the site.

Everything that we don't spend on producing the show will be donated to the PSF to keep the community alive. We're recording today on August 8, 2015.

Your hosts, as usual, are Tobias Macey and Chris Patti. And today, we are interviewing the core developers of Nikola and Pelican about static site generators.

So could you please introduce yourselves, Justin?

Certainly. My name is Justin Mayer. I lived in Japan for a while,

came back to Southern California where I'm originally from, and I design and build software here, both web applications,

mobile applications.

Some other things I speak at conferences occasionally, I've spoken at PyCon, DjangoCon,

Southern California Linux Expo,

on a variety of topics including

static site generators. Currently working on

2 major

projects. 1 is monitorial.net

which is a

Python powered server security monitoring tool to help you have a better understanding as to whether your servers have the latest security updates applied and other sanity checks.

And the other 1 is Uprise,

which is spelled with 2 i's, and Uprise is focused on providing a better concert ticketing experience and eliminating concert ticket scalping, which, of course, everyone hates.

Also love craft beer, good wine,

traveling,

and tinkering with things, whether that's

keyboards or computers or really anything that I can take apart.

Excellent. Roberto, how about you?

Okay. My name is Roberto Alcina. I live in near Buenos Aires in Argentina. I work for Canonical on things I am not free to discuss at this moment.

So that's going to be awkward.

I have been involved with Python for a really long time.

I have spoken in different conferences and all that stuff because have done a bunch of projects, which are pretty much abandoned except for Nicola at this point. But I have had a lot of fun with it, and I love the language. So

I write about it and

talk about it in conferences and all that stuff. Other than that,

you know, just a regular guy. Nothing really interesting.

I doubt that.

So how did both of you get introduced to Python?

I started

using Python when I created a commerce business a few years back importing products from Japan and other countries in Asia,

and I needed

a way to get the order data out of the,

out of the order system

into the payment processor, and then after that into the

logistics service that I was using for picking, packing, and shipping.

And it was a very cumbersome process initially. I had to export things as, CSV files and then figure out how to get it into the

respective

services, and Python made it easy for me to write a couple of scripts to do that. And I it was something that I needed to automate.

Python seemed like a good tool for the job, and that's how I started using it. And then I needed to publish something years later

and was looking for a way of publishing things that was a little bit

better suited for what I was trying to do than

WordPress or Drupal or

any of the other common PHP based publishing tools allowed,

and that's how I came across,

Cenex side generators and and Pelican and then eventually, like I said before, that sort of parlayed into,

monotorial which is uses Python across the board.

Everything from the agent that runs on the server to the web service that it communicates to

to the web application that end users log into.

Roberto, why don't you tell us how you got introduced to Python?

Okay. This is going to make me look even older than I am, but it was 1996.

And I was starting to play with Linux, and

I was trying to write code. I was not much of a programmer yet. Not that they are now, but anyway, I was

really beginning I was beginning to program. I was really frustrated with c and c plus plus

and I wanted to write,

graphic interfaces for applications.

So I found something that was called Xforms,

which was sort of free graphical toolkit that nobody remembers anymore.

And

I also hated that I had to write the programs in c. So I learned Python, and the first thing I did

was write a binding from Python to this graphical toolkit,

which I released it and nobody used

in 1996, like I said. And then I forgot all about it until 2, 009

when I actually tried to build it again and it still worked, which was surprising. I I I kept using Python for different things. I was a, network administrator.

So I wrote little tools,

things like that. And I pretty much have not really used any other languages since then. So it has been

almost 20 years.

Now that I think about it, it's scary.

And I have been working with it. I

started

keeping a blog somewhere around year

2000, and

I always use custom things I build.

And I was doing static site generator since pretty much

back then.

Nikola is the first 1 that's actually public and other people are using. So

really

long convoluted way to get here, but

I I basically wrote Nicola because I didn't like the other static site generators because I couldn't import my really complicated blog I had, which inherited

the path structure from software that nobody even remembers now anymore.

So I wrote my own.

And then I published it, and people sort of liked it, so I keep using it.

For our listeners who may not know, what are static site generators, and what are some of the advantages they bring to the table over other similar systems that perform the same function?

So, basically, static site generators

take all the they remove all the effort from the computer that serves you the website. Usually, websites,

you

read the page, and then the page is custom built for you just at that moment.

It checks things with databases.

It runs programs on the server and does all sorts of things so that in the end, you end up with

HTML text in your browser. Right? In a static site generator, all that happens

before. It happens much earlier in the process. It happens on somebody else's computer, then the results are uploaded to the server. And that means the server already knows what you want. It will give you the the static web page you really need, and that's all it's going to give you. No code runs on the server. No database runs on the server. And that means the server doesn't do much. It's really light, doesn't need a lot of resources,

has

a much smaller surface to have security issues, and usually work faster.

Yeah. I would

highlight a number of of those things.

The better performance is a is a concern for anyone who is lucky enough to,

achieve some success with a particular

article that they published if it gets picked up by a number of different,

you know, news aggregators, the last thing you want is for this flood of traffic to

result in,

server errors. So not to mention just the general performance. If if it loads it takes 10 seconds to load, you're unlikely

to have folks stick around to see what the actual content on the page is.

So both from a perspective of better performance

and better reliability and uptime, I think static site generators offer quite a bit over their

more dynamic content management system counterparts.

Another significant

advantage

is security.

When you have a a static site, it's it's just a bunch of

static assets.

So you've got some JavaScript, HTML, CSS.

The the attack surface for someone who's trying to do something nefarious is much much lower with a static site than with a content management system that's running on an application server

that is executing,

you know, instructions

on every page load.

The deployment and maintenance is easier. You know, you generate your static assets. You use your

preferred

file transmission tool of choice to transfer those files to any number of different deployment options. You can deploy to

your

own virtual private server. You can deploy to GitHub,

s 3.

You know, there are umpteen other different deployment options that are greater than you would say have if you're tied to a particular

web application stack like WordPress or some other content management system. An ongoing maintenance is easier. The you know, you might update your static site generator tool itself,

but that doesn't really impact what's going on on the live server. If you are, say, updating your WordPress installation and something goes awry, well, your site's now

offline. That's not something that would happen with a static site generator.

You might update your static site generator tool

and generate

the

your site and notice that something's wrong, but that's all happening locally. It's not happening on your live server.

So it's, it's quite a bit easier to maintain.

I also find it that it's easier to version your content. So if

you're just dealing with

text files on your own system,

you can store those in a version controlled repository, whether that's Git or Mercurial or whatever your tool of choice is. And it's I find it much easier to version that content over time than it would be using a database backed

content management system. And you can also version both your input and your output. When you have a a website that's managed by a database, you

it's really hard to,

version

the actual text that you write for your site

that's

hidden in the database.

Yeah. That's an excellent point. And and people

should be mic should be versioning both the source content and and the generated output. Because if you were to update your tool and you were to accidentally

deploy changes to your production

environment that you didn't really intend to or you've later found

included some problems that you wanted to revert to, it's much easier to make that reversion if you have your output version as well. And just the last couple of things that I'll I'll say about the advantages of a static site generator are, you know, you're dealing with just files. So to me, it's just a simpler thing to to deal with. You have files on on the input side, you have files on the output side.

And it kind of adheres

a little more closely, I think, to the Unix velocity of

files as opposed

to having to interact with a database that you have

to back up and manage, and it it's just it's a it's a lot less overhead in general. And the last thing I'll mention is you have better control over your own data.

When you have all of your content in file sitting on your system that you are pushing somewhere else,

you always have the most version the most recent updated version of your content because it's on your system to begin with. That's where it originated. That's where it was generated. That's where it was transferred from.

If you're making all of your changes on a remote server, you have to remember to try to periodically

extract

and back up and and pull that data someplace where you have a little bit more control over it. So I think just having better control over your own data is a pretty significant,

advantage for Stack's site generators?

Absolutely. Simply not having the requirement of a database

is such a huge difference. I mean, that's kinda 1 of the things that drove me

away from WordPress and towards,

a static site generator

is the fact a number of the things you mentioned, but the thing that broke the the camel's back for me was,

the fact that

it was so hard with WordPress

to manage

all the all the complexity. You know, like, PHP gets updated, and now suddenly something doesn't work. Or or, as you said, you have a database to to take backups of and and and worry about security of. And it's definitely

a huge relief when you realize the only thing you need running on your, sort of, publicly

hidable node

is your web server

of choice. And that's it. No CGI needs to run at all. In fact, it's a liberating feeling actually.

Absolutely. It's

the curse of software is complexities.

That it's complexity that generally introduces

the problems that we face on a daily basis, the

problems related to speed,

performance, problems related to reliability

and uptime,

problems related to

security.

These are all problems that are in large part caused by complexity. And when you have a simpler tool, it's much easier to manage those

inherent risks in software.

And that was it sounds like something that drew you to it as in and I think that that's a large

part of its popularity over time is is that simplicity.

Yeah. And I'll also say that going back to both performance and simplicity,

because it's just static files, it also makes it much simpler from a caching standpoint where you can just put a CDN in front of your you know, wherever you're hosting your site. And even if your site actually goes down because everything is a static asset, it's very simple for a CDN or a caching system to just display the site as it would have been had you actually gone back to the source. And it can also significantly reduce the amount of load that needs be supported by your server, which means that you can spend less money on a hosting solution.

That's absolutely right. That's, those are all very

significant advantages for for someone who's, yeah, who's interested in dealing with some of the

slightly

less than user friendly aspects of static site generators, which is a whole another topic in and of itself.

And the other advantage as well, going back to your point about ownership of your data, is that it

prevents vendor lock in because since all of your content is just in static files and usually written in either markdown or restructure text or some other form of simple markup,

it really makes it a lot easier to take that content and move it to a different tool chain

and not have to deal with any potential data loss in the migration

or issues with incompatibilities

between your source and destination systems because all it is is just text.

That's right. You can always point wget at a WordPress site, for example, and have it pull down all of the the generated

HTML and and JavaScript and CSS and then take that and then, in theory, upload it someplace else. So there are ways of migrating other things, but I agree that it's really not a 1 to 1 comparison. It's it's much much easier to migrate

something that's a static site to begin with. There are there are issues with using sort of a blunt force tool like wget to to mirror the contents of a site. If you try to migrate the WordPress site that way, you're going to end up with uneditable files because you download a a post, and it's going to be the whole page. It's going to have all the Chrome around it, all the decoration, all the sidebars, and all that stuff.

And, in fact, most of that is going to be broken anyway after you move it to another site.

You cannot actually edit that anymore. It's just a read only copy, and it's not the same thing.

When when you have

a literary markup for your posts and your pages and so on, going I don't know. Going from Nicola to Pelikan, it's probably going to take 5 minutes for a a normal site. It's mostly going to be about

how do I get the metadata for the post, like tags and categories and such and move them to the place the other software wants them?

But it's really just a scripting thing. It's not a big problem.

I have written the code to import from WordPress and trust me, it's not easy even using a dump

because it's not documented anywhere. Even the the the format of the input of WordPress changes after you install plugins. So

you have applied and now the input for your WordPress is different from every other WordPress installation in the planet and no other WordPress can read it unless they have the exact same combination of plugins,

which is incredibly frustrating.

When you try to get code outside of it, there's a lot of luck in that sort of system.

Yeah. That's a really good point. There are a lot of,

issues

revolving around WordPress

import. We see people

ask questions,

that Pelican issue tracker

regarding WordPress import, and

oftentimes we

are ill equipped to assist because we have long since left WordPress and its ilk behind.

So we have to rely on the community to try to help out with a lot of those questions. And, yeah, Roberto, you're absolutely right. It is not,

it's not well documented.

WordPress is

not something

that's easy to interact with, and,

yeah, vendor login really is a very

significant point

in terms of trying to choose

what tool you're gonna use to publish.

Vendor lock in is something that you that people certainly should consider.

Yeah. That's a big reason why when I was first starting up my blog and also the website for this podcast, I decided to go straight for a static site generator,

just start writing some content, and SCP it up to my Linux server, and there you go.

So there are a number of static site generators available in virtually every programming language that somebody would be wanting to use. Why would a user want to leverage a Python solution versus Ruby, JavaScript, Go, or what have you?

I think that folks

who are already

interacting with a particular programming language, whether it's Python or Ruby or Go or JavaScript or Rust or

Nim or any other language that they that they might be excited about,

That's always a good choice.

It's the reason that I

originally sought out a static site generator that used Python as its,

is the language that it's implemented in was so that if I decided that it didn't do something that I wanted it to do, then I'm better equipped to extend it to make it do that thing that I want it to do. So just to use Pelican as an example,

I

found that it did not,

apply certain typographical

enhancements

in the output

when I first started using it. So things like curly quotes, things like taking a a double hyphen and turning them into an em dash,

ligatures,

widows and orphans, and there's umpteen

different

things like that

that typographical nerds like myself are somewhat

fixated on, in terms of when I'm looking at generated output.

So I submitted a pull request to, to add that particular

feature. So

I don't know that there's

too many things

that are specific to Python

that make it, you know, sort of heads and shoulders a better solution for static site gender than any other language.

Obviously there are a lot of libraries, so for example the typographical enhancements that I'm talking about I was able to

to leverage a library called typography.

In order to do that I didn't have to to write that myself. So library availability

would be a factor

If you're, say, trying to use NIM or or Rust or or some relatively,

you know, less mature or or newer language, you're gonna have a more difficult time finding those types of libraries to to extend the tool to do it to make it do what you want it to do. But that would be probably the only thing I can think of. Roberto, can you think of any other things that are sort of specific to Python that that that make it a great language for a stack side generator?

Okay. Yeah. I have 1 specific I mean, it's something that was something I wanted.

I was I have always been a big fan of restricted text,

and that means Python.

There is another implementation of it, which is in Haskell.

So you have to choose Python or Haskell. And to me, that was an easy choice because I know know Haskell.

So

in fact, in Nikola, we we try

to support as many

markups as we possibly can,

and Python is really good at that because we have,

restricted text. We have

6 implementation

of of markdown around. We have,

textile,

text to tags,

and so on and so forth. There's

an absurd number of of markups,

and

that's important because people can write them can then write in whatever they actually feel comfortable writing with.

In my case, that was restricted text,

and that meant Python.

That's a very good point of

the markup support because, as you said, you prefer restructured text.

Some other people may prefer markdown.

And having good broad support for various markups

does make Python a very good target for that. I know that in

Ruby, some of the static site generators there use Haml as a markup language because it's something that's been popularized

as an add on for the Rails framework.

So

the language affiliation definitely can make an impact on what you actually have as an option for writing your content. So that's a very good point. Hadn't thought about that. I suppose there is a power static site generator somewhere that uses pod or whatever.

We just never heard about it. Yeah. That's a good that's a good point. Another markup format is Asciudoc,

which is a Python based

library.

And that's easier for you know, obviously, if you're writing a static site generator, just for ASCII doc, if you're using a Python based static generator as opposed to Ruby or something like that.

Yes. But sadly, ASCII doc in Python is sort of dormant, and all development right now is done in something that's called AsciiDoctor,

which I think is written in Ruby. So Oh, interesting.

Except because Askeydoke is very nice.

Well, I suppose that gives our listeners something to work on to improve the Python ecosystem.

So it seems that most static site generators have a primary focus on blogging. What is it about these tools that lend themselves so well to that use case?

My take on

this question is that

it's

the people that are writing static site generators

are the ones that shape what the tool is focused on. So I think most folks who are

building static site generators

are most interested

in scratching their own itch and most of the time that itch happens to be

publishing

chronological

content. They're writing articles. It's not so

much I want

to publish a site that

has an about page and maybe a contact page

and maybe some photos of my cats. I I think that that's much less common than someone who says, well, I want to publish a site that has articles and people can come and read those articles. And so because that's what the people who are building these tools are interested in doing, I think that that's why you see

that that sort of focus on chronological

content and articles.

I don't know that there's anything

specific, you know, both in,

obviously, in in, Nikola's

case as well as, Pelican and and a lot of other static site generators.

There are almost always

ways of producing sites that have 0 chronological content and are entirely focused on

creating

pages,

of in any type of hierarchy that people generally want to do. What what do you think about that, Roberto?

I think part of the reason for this is that the design generators

are mostly popular among programmers.

Programmers are in

much more likely to have a blog even if they only update it occasionally than in other people.

Also, the parameters are sort of fanatic about

workflow and optimization

of their workflows.

That means that they really appreciate what happens because,

how do you work on a problem? You start a branch or whatever, then you write code, then you commit, then you push, then you release. And, statistics and data has pretty much the same workflow.

You start the post, you write in it, you build it,

and then you release it. It's

more or less the same thing. The workflow is really

programmer like.

That's probably also why we have so many static site generators because as we all know, programmers like to rewrite things.

We always think that we can do it better than everybody else. So

we start a new

study site site generator just for our site.

I think that's

mostly

why this happens. And then

we also get a lot of requests about

sites that are not blogs

because then

we have to write sites for our programs. So

they also need a site and that's not a blog.

But, yeah, I think a lot of the feature set of static sites and items is

forced by the audience, which is still at this point mostly for others.

Yeah. And I'll add to that. I think part of what lends static site generators so much to the blogging use case is that

because

they're generally focused around a repeatable task of generating the site in the same manner every time.

And most of the time, you're not going to be iterating that many times on a content page or an advertising

page. Whereas in a blog, you're constantly creating new pages. And so

having that workflow of being able to add those pages in a repeatable and consistent manner

is more well suited to blogging than it is to just creating a landing page, for instance.

Yeah. There are still advantages

to using a static site generator

even for a

site that doesn't include any

blogging or chronological

articles. So as an example,

the use of templates

is really 1 of the key

points of value, I think, for a static site generator.

For example, if you have

a a header, a footer, a sidebar, something that's supposed to be consistent across pages,

Using templating systems like Jinja, for example, or Mako or,

you know, other non Python based templating systems,

you can create

the layout for those elements

and change them in 1 place. If you were, say,

to have even

only 5 pages and you thought to yourself, well, I'll just do this using HTML,

and I don't need a stack site to your Internet. It's only 5 pages.

You might find

very early you know, very soon

that when you have to modify something in a footer across

5 different pages

5

times,

that that process gets old and tiresome and tedious very quickly.

And that's 1 of

the advantages that using a a, static site generator offers is because it is built on top of that templating system to begin with.

I suspect if somebody is doing that by hand in HTML, he's still using a static size generator. So it's a really crappy 1. That's

himself and his, text editor.

And he should get the better 1.

Mostly nowadays, when somebody starts doing a site, even if it's just 5 pages, he's going to go to a CMS,

which is,

I don't know,

to me, person doing a static site generator makes little sense.

But to somebody, hey, let's just throw a WordPress instance somewhere

and log in and write 5 pages and be done, install a theme.

And for them, it makes sense. It takes 20 minutes

to do that.

So,

you know,

it's it's all about workflows. People work differently, and they make different compromises based on what they want to do and how they feel comfortable doing it. Well said.

So

something that struck me comparing the 2 systems

is that they have largely the same kinds of data going into the metadata block for each post, but it's expressed in a different and incompatible way in each. Have you ever considered agreeing on a standard and even advertising it as such, so all static site generators could make use of it and this plays into your vendor lock in point from from before?

It's an intriguing idea.

At first,

I was trying to

work through the idea and and see, you know, how that would work, and it is an interesting

concept.

It is a little challenging because it does require

coordination across,

obviously, a very wide range of

of tools. Yeah. Not that you would have to start out with

with every tool using it, of course.

But trying to build consensus

in general is is a challenging thing to do.

And when you have this many different tools,

they tend to do things in their own idiosyncratic way because they're, like Roberto said, trying to solve

the particular needs of the person who implemented it.

But it's an intriguing idea, and I would certainly be interested in exploring it. I think that just as a caveat, I would say that it's useful in a rather limited set of circumstances.

If you think about the use cases, it it would generally be if someone is

migrating from 1 tool to another.

And not to say that that never happens

and not to say that it wouldn't be nice if it were easier to do that. I can see that that would indeed be a nice thing to have.

The question for me becomes,

is the

benefit

that accrues

for that particular use case worth the amount of coordination,

and logistical,

you know, challenge

to to have such a standard and and to get people to agree to it. But it is an intriguing idea.

Yeah. It is. There is

some parts of this that could be done rather easily. Like, for example, how we express metadata for posts

and basis in the files, that sort of thing. That that's not all that difficult to do.

There is different problem about how that gets built into a site because, for example,

some tools try to reflect the

the file structure, the directory structure of the input in the output, and some don't.

Some build based on the metadata. Like, if a post has a category, it goes into whatever slash the category name slash the post net title, etcetera.

So you won't end up with the same site even if we agreed on how things

how the input works. But I think agreeing on how metadata

is expressed on the input files, that's not all that difficult to do.

But the problem is suppose I write a standard for it and I propose it, then

nobody's going to adopt it. They they will see no benefit

on doing that, I suspect.

I just wanna give you just a little quick background as to why I asked the question. I asked the question because

I'm currently using Pelican for my blog, and I've I've kind of been playing with using Nikola as well. And they're both great systems, and I I don't know whether I'm gonna switch. But I thought to myself, how amazing would it be as an end user if I could just take my body of posts

and no matter which static site generator I used, just be able to treat my posts as portable datasets that could be moved from 1 to the other

without change. And even if everybody supports a common subset of metadata items. Right? And because of the idiosyncrasies

and the way everybody solves problems differently,

it's okay if it comes out differently,

you know, given the same set of data, which static site generator you run.

But it was just a thought that it would be nice to not have to necessarily

undertake a conversion and just be able to take the same dataset and move it anywhere I wanted. That's that's what I was thinking of. Maybe perhaps that's an unrealistic thought, but it it occurred to me, it's partially because of the, what's his name, Jeff Atwood there. He made a post a while ago basically saying, hey, guys.

Why is it that we have 19 different

incompatible

versions of the markdown

spec?

It's kinda crazy. Why don't we just all agree on some basic defaults and

have a unified markdown

syntax that could be used everywhere.

And it it kinda never happened, but it it just kinda got me thinking. Wouldn't it be great if the the same held for not just markdown, but,

but metadata as well. You you convince me. I I'll do it.

I I I make I make Nikola accept, Pentagon

files for it.

You'll have it by what's today? It's Monday?

Come back to me Thursday.

Wow. That's very cool. Now that's what I call service. And I'll also add that having the capability

of, as Chris mentioned, just having a common subset of metadata that supported across multiple different generators really facilitates the process of experimentation,

like exploration,

and being able to run different static site generators against the same content so you can see what the workflows are like, what the templating systems

provide as options, and then being able to make your decision based on that rather than just having to read through the feature list of of all of the different umpteen static site generators and say, well, I think this 1 fits my needs. I'm gonna go with that 1. And then having, you know, very lightweight vendor lock in, but it still locks you in a little bit just from the inertia

of having to take the time to add or modify the metadata of your post so that you can do that experimentation process. So that's excellent to hear, Roberto, that you are going

to accept Pelican's metadata formats in your system. I

think it's a wonderful goal to have, you know, in terms of having that kind of portability.

There are some inherent challenges given

that different static site generators often will use different

formats for metadata. So for example,

there are some Ruby based tools that use YAML as their post metadata format.

So even if you were to agree, say, on the keys,

that are used, things like title, date,

summary,

etcetera,

the format of the metadata itself can be different enough

that standardization

becomes

nigh on impossible.

But I think that

in this particular case that we're talking about,

given that both, Nikola and and Pelican both use

the Python

markdowns

implementation

of of metadata,

that it wouldn't be too awfully difficult

for tools that are using Python markdown.

They're using that particular library to

say, let's try to agree on a common set of

metadata

keys. Things like tags,

categories.

We you know, Pelican uses 1 called,

draft, which basically means is this post a draft, and if it is, treat it differently

than than a non draft post so that it doesn't actually get published to the, you know, to your site. But it would be nice. So, Roberto, if you're up for it, I I would love to have a follow-up conversation where maybe we could talk about ways in which we could make that portability a little bit more, yeah, make it make that more feasible.

Basically, Nikola doesn't have a a fixed set of metadata fields. You can put anything there. But,

we use, the basic stuff like tags, category,

title,

that sort of thing, date.

So it should not be

really difficult.

I I just

luckily, a couple of months ago, I made that a plug in. So I can just replace it with another 1, override it, and then it reads Pelican

posts. It's

probably not all that hard. I can like I said, give me a few days. I have ample free time in at lunch.

Yeah. And that that's great for interoperability, you know, between the the 2, but it I think that there's there's this very

interesting, you know, broader point, which is if there are other tools out there that use the same

format

for metadata. It would be nice if if we had, you know, some

common agreed upon. So, yeah, I would be I would be interested in exploring that. So I I think that's, I'm glad that you guys brought it up. You you know how you find what does what's the common

parts of the metadata. Right? You try to use the metadata from the other guy in your program, and then the parts that you can use, that's the common part.

So I will know what the common part is in a couple of ways.

Sure.

So pelican also allows

the ability for people to put in whatever arbitrary

metadata that they want into their posts. So that that's just part of the underlying Python markdown library,

and any keys and values that are put into that metadata can be

used on the template side of the equation

to perform whatever type of related

operations you want to do. But, you know, there are things that where the where the tool behaves differently. So like I said before with, you know, whether it's draft or whether it's tags or categories, there are certain things that that Pelican does look for. And if we could, you know, if we could find a way of standardizing

those kinds of commonly used keys, that would be really, would be a really interesting idea.

Yeah. Let's do it.

So the themes in Pelican and Nikola have very different feels. And 1 of the things that initially drew me to Pelican is the larger catalog of themes available.

What are some of the challenges involved in creating a theme for a static site generator? And

as a tie in to this discussion of compatibility,

what are some of the challenges that could be overcome in terms of making a theme that could be used among either both Nicola and Pelican or even maybe against other

site generators as long as they're using the same templating

system?

Basically, a theme takes a bunch of things in the that's called the context.

Mhmm. And

a static site generator provides each each 1 provides completely different things there. Standardizing that would be

10, 50 times harder than standardizing the input format.

For example, we have, like, magical things that you write link column /tag

/tagname, and it will link to the tag name. And that's not going to work anywhere else because something I came up when I needed it.

It's totally

just

random. There there is no

design behind it, and

I suspect most other SSG have the same

sort of thing.

I don't expect that's doable.

The main reason why we have few themes is that I suck at HTML. The the the most of the latest themes have been done by other people, and the few I've done, I just took another team from another SSG and stole it. And it's rather easy. I mean, I can still do anything in probably about half an hour. Nowadays, I have practice.

I just take the outputs,

split the HTML in pieces,

and make it into a template. It's not it's not difficult.

Well, Roberto, as opposed to saying you steal it, why why don't we just say that you are

proactively adopting

successful

themes used in other projects.

You know, we all build upon the backs of giants. Right?

Oh, yeah. I I keep credit. I I don't really steal it. Come on.

I only take things where the license allows me to, you know, take it and change it and do it my own. But, yeah, that's the main thing. I mean, Nikola is already a pretty old thing. It has 3 years.

It's 3 3 and a half years old.

And

I don't like that we have so few themes, but the main reason is that I don't we don't have much

in the way of, actual web people working on it.

And that's mostly why we have few themes.

I agree with that. That's

that's exactly what I was going to say is that if you look at the the types of people who build static site generators and the types of people who are most interested in using

static site generators,

these are, shall we say, terminally minded folks. People who are comfortable using a terminal, people who are comfortable typing

in arcane commands

into a command line.

And this is a very different type of person, generally speaking,

than someone who's

who spends a lot of their time thinking in in more, shall we say,

artistically creative ways. I just think there are different skill sets and so

the other the other part of it aside from different skill sets is motivation,

particularly

if you're talking about the person,

actually in either case. People want to publish their content.

Their goal for either creating or using static site generator is that they have this content and they wanna publish it, and they wanted to do it as easily and as painlessly as possible,

within reason.

And I think that the

the idea of saying, okay. Well, in addition

to creating and or learning how to use a particular tool, I'm going to also

craft

a brand new theme. I think that most people that's just a bridge too far

and they're more interested in utilizing

a theme that someone else has created. And so when you have, like, 98% of people interested in utilizing the themes that the other 2% have created,

you sort of end up with this

somewhat of

a less

larger catalog as

perhaps

the particular

ecosystem may might want.

But to answer the underlying question,

it's not that themes are all that difficult to create,

it's just a question of like Roberto said taking your your page and dividing it into its its different components and then splitting that into different template files. But that also

assumes that you have a page that you really like

and and that you understand

how the design elements work and you understand,

you know, what would be involved, like how you would break it up into the different components.

And and I think that there's just an,

there's just enough

friction there. But it's it's a it's a it's not a huge challenge, but it's enough to

get people to say I think I'll just use something that someone else created.

Guilty as charged.

Yeah. I think we all are.

Yeah. Basic

I started sort of an initiative to get a new theme in Nikola because I hated the ones we were shipping, and what I did was exactly that. I went,

I think, to Octopress,

and I found 1 I like. It was called Lanyon, and I totally copied it. And it works exactly the same.

But, yeah, I don't like doing web pages. It's weird to say that when you're writing a program to make web pages, but

I don't.

It's a common sentiment, and, it's funny that that you mentioned Lanyon.

A,

a member of the Pelican ecosystem

contributed a version of Lanyon for Pelican as well. I mean, it's a very nice looking theme that comes from, you know, the the Jekyll universe.

And,

yeah, I think that that's a very common approach. Someone who sees something that they like and says, oh, that would be cool if it existed for my tool of choice. And

at that point, it's not too difficult because the creative work's already done and they just have to do a little bit of

the shoehorning into the the format that the particular tool expects.

And, yeah, it's it's something that's

an issue, I think, for a lot of different tools

and, it would be just going back to this question of, like, you know, is it would it be possible to create a a cross

tool,

theme

standard for lack of a better word? I agree with Roberto's assessment.

If if having post metadata standardization

is hard

and challenging,

the themes are gonna be that much harder.

They're just

architected in such a way that they're very peculiar

and in particular to

the underlying tool, and, it's not impossible,

but I think it's

it would be very challenging to do that.

Yeah. I recently decided that I want to try and create a new theme from scratch. And like you said, having to do all the creative work right up front and figure out, okay, these are all the different elements that are gonna be on the page. This is how it's gonna be structured.

Coming as a non designer, somebody who's, as you said, very much terminally focused,

it it's just so much of a different

portion of your brain and thought process that you have to employ

that so far,

I've had a couple of false starts. And

1 thing that I can say is that as far as trying to think of an approach to simplify that

is I know that with Pelican, you can just override the base theme incrementally, and I believe Nikola has the same capability as well. And so that's going to be my approach going forward is because

particularly using a templating engine, when you're starting from scratch and you're trying to just design, for instance, the frame of the landing page,

trying to include all of the different

templating syntax

and account for the various metadata elements that might be included, it gives you a hindrance in being able to get started. Because

since you're starting from scratch, because you're not overriding

things to begin with, it prevents you from being able to actually create the page and see

what your results are so far.

And so I think that starting from those base templates and just overriding things incrementally will be a better approach because then you do have the capability of, okay. I'm gonna generate the page, see what actually resulted from these changes,

and then just keep going in that manner.

Right. 1 of the things that just as an interesting anecdote. You know, Alexei is was the person who originally created Pelican back in 2010.

And

just to show you sort of someone who's creating a static side generator

and who's trying to decide

how they want the the styling to work, he came across a post from 2, 009 in Smashing Magazine and said oh I like this design and essentially

repurposed it as the,

as sort of the design for the site that he was trying to create for himself.

And to this day that's the the default, you know, theme in in Pelican until we until we replace it with with something different at some point in the future. But to me it's it's very telling that this is the sort of way in which you know, even tool designers and and builders

approach things. They they find something that they like and and say, well, I'll just use that rather than trying to handcraft something myself.

The the default theme for Nicola was an absolutely horrible theme I had on my personal website

until we replace it with Bootstrap,

which is, like, the worst idea ever because every site looks like Bootstrap.

And we still have that 1 as default now.

I hope I can replace it with something decent.

So perhaps we can put the call out to our listeners that if anybody there is a Python developer

or even not a Python developer, but maybe listening to the podcast who has some design skills,

maybe

help these folks out and write some excellent looking themes for these static site generators so we can have our cake and eat it too. And also improve the adoption of Python as the best tool for everything under the sun.

Excellent. Very well said.

So Pelican and Nikola seem to be the most widely used projects for creating static sites using Python. What do you think is the key to that popularity?

It's funny when when I think about this question.

I had originally, when I was searching for a Stack side generator, this was back in

2011,

I believe.

And at that time, there was a very,

there was still a very decent number of static site generators. Nothing compared to the number today that's, you know, probably an order of magnitude higher. But at that time and I still have this this document that I

that I used in terms of jotting notes down. I'm like, okay. Well, there's there's this tool, and and I wrote little notes next to them to each tool so that I could come back to it later and and try to make a decision as to which tool I I wanted to use.

And this this was even before,

I don't think I don't Roberto, I don't think you had written Nikola at this point. So it's it's not in my list.

And

so 1 of the items that was on there was Pelican and it says,

I'm actually looking at my document, it says updated frequently,

many contributors,

good documentation.

And to me I've mentioned that only because I think those are the the reasons why

these tools are so popular. I think that

anyone who's

trying to make this evaluation, right, even though as we've mentioned before your your ease of migration, your data portability,

your your lack of vendor lock in is improved using a stack site generator, there's still

this feeling that if I choose a tool and then I decide that there's this other tool that I'd rather use, I'm gonna have to do a lot of work. And and and that's probably true to some degree.

And so people have this feeling of, well, I wanna try to choose wisely.

And I think that 1 of the things that some of the things that people look for when they're trying to make that determination

is, you know, how active is the development? You know, how many contributors are there?

What does the ecosystem look like in terms of extensibility,

plugins, and themes? I think that the documentation

is key and Nicola in particular has excellent documentation. I think

Pelican,

we could do better in that regard.

But I think at the time Pelican had the best documentation of any tool that I could come across. You could actually look at the quick start and you could get up and running

and I think that that's part of the reason why these tools, you know, both, Nikola and and Pelican are are popular.

A lot of it comes down to just how

quickly can I get up and running? Do I, you know, am I yeah. I just as another anecdote, I had used a tool prior called hide, which was written

as sort of a counterpart to Jekyll, you know, a Python based static site generator, and at the time

it wasn't, maintained very well. But the the main issue that I had with it is that I could not, for the life of me, figure out how to do very basic things with it because the documentation

just was not adequate. And so I think that the the documentation really is key. I think the most important thing is that you the user should be able to get a site working

with something he wrote in it in 2 minutes.

If he cannot do that, he's going to try something else.

In the in the Nicola documents, I wrote something that I'm not sure is a good idea or not, but I don't want to remove it, which is the first thing the document says. It gives you, like, 5 commands,

install it, then run Nicola, init Nicola, whatever,

and then try to use it and do not read the documents.

If you need to read the documents,

then the software is wrong.

You should be able to get it working with just knowing

3 basic things about it. And if you can't, then it has to improve. I still make the effort to write the documents,

but I would much rather the user don't need the documents.

I have completely failed at that until now, but I still have hope.

And you can actually do interesting things without reading them. In any case, I think that

really short ramp up is the key thing

because people are going to run away from your software.

If they are going to run away from it, they are going to run away from it before they are invested in it. They

are

logged

in

at

least

a

little

bit,

and

then you they are logged in at least a little bit,

and then you have a user. It may not be a happy user, but you'll have a user.

That first impression is the key thing to keeping users.

Yeah. And I think that the extensibility

is another

key component. Having

a wide variety of of plugins and and themes, I think, is something that

is useful for folks who are trying to,

you know, particularly

plugins. I mean, if as long as you can find a theme that you

are satisfied with,

you know, you're for for the foreseeable future, you don't really need to do anything further regarding that. But as you

use a particular tool and you start to publish

additional,

types of content perhaps,

you might find that you want to do something that the tool doesn't do. And if there,

if the tool wasn't built for extensibility

in mind, if it doesn't have a

wide range of, existing plugins

you might find that the thing that you want to do is more difficult and you can always write your own if the tool is made to be extensible in the first place. But if someone has written a plugin that already does what you want it to do, then all the better. You don't have to spend the time to learn how to

write a plugin and and implement that functionality yourself. So I think that that extensibility,

in terms of, you know, the modularity of the tool as well as the availability

of those components, plugins, and themes is another

key reason for,

the the popularity of of both, Nikola and Pelican.

Totally agree.

Writing plans should be as easy as possible,

because everybody wants something that the tool doesn't do yet, And they can either write it write it themselves or just going to have to ask developers for it. And if the clients are easy to write, it's more likely that they will do it. Actually, I am surprised. At some point, I did some statistics on Nikola, and we had, like this was a long time ago. We have, like, 100

sites working with Nikola, and we had, like, 45 contributors

to the code base because everybody found things that Nikola didn't do, and they added

those things.

Nowadays, that has slowed down a lot because it already does a lot of things. But, yeah, extensibility and an easy path in into the the code base are are really

important.

So a lot of people have written about the importance and difficulty of writing and maintaining good documentation in open source projects.

Nikola's documentation is excellent. How did Nikola manage this in its development process, and what can other open source projects learn from this?

I write a lot.

There's no secret to documentation. You just have to write it, and then you have to keep it updated. It takes time, and nobody likes to do it. But I do it anyway. That's

sorry. That's the sad version of things.

I I guess the answer

is you are Nicola's author, and so it falls to you. It's not like you have a huge cast of characters

who are working on Nicola's core that you have to get to write

documentation. There there is, basically, Nicola nowadays is written by about 3 or 4 people. Mostly me, Chris Warwick,

Steven Alexanderson.

He does a lot of things.

He's the 1 that knows HTML,

so

I want to keep him happy. And I am the 1 that writes most of the docs because

I don't hate writing docs. I do that a lot. And I want it

to be documented. So if I want it to be documented, I need to write it.

It's that's how it works. I I'm not going to reject

a branch because it doesn't have documentation,

so I need to add it.

Justin, do you have anything to say on on good documentation? Because as you mentioned, and as Tobias mentioned, Pelican has some great documentation as well.

I think that

looking at how a user

approaches your tool for the first time in

without the usual

perspective that you have as someone who interacts with the tool on a daily basis

is

particularly difficult

just in general for for anybody. So being able to say, what is it like to use this tool as a first time user who knows nothing about it? That that's something that's difficult for for people to do who spend all of their time

working with it. You you become so

used to,

the the rough edges. You you just take certain things for granted.

And to the extent that you have an ability to say, okay. I'm going to try to put all those things out of my mind and approach this as if I were

a first time user.

To the extent that you can do that, that's fantastic. That's wonderful.

It's it's very hard to do, but I think that it's a it's a good first step. It's a it's a good good way of approaching the question of documentation

to begin with. And then

having

a open,

forum

for

people to suggest

improvements,

is another useful

tool. I think that

it doesn't happen as often perhaps as 1 might like. You and we will receive pull requests that say, I found this particular thing confusing

and think that it should be clarified.

Like that's much more common than someone says, I found this particular part of the documentation confusing

and here's a pull request that adds some additional language

to potentially make it less confusing.

That does occur, just not at the same frequency as someone who is

saying, I found this confusing.

You guys should fix it. But I think that at least encouraging people and when that does happen, by the way,

you know, we will often ask them, like, hey, if you don't mind, would you consider

perhaps submitting a pull request to

clarify because we don't know which part of it they found confusing, and we don't know

in what way

they might find it less confusing. So if they're saying we I think that this particular section could be improved. Okay. Well, how could it be improved? And if if they can help out with that, that makes

the job easier for everyone because we don't have to try to read their minds and and try to sort of pull out of them what it was that they found confusing and and what it what it is that they think could be improved.

So encouraging people to help out with it,

I think is a is a really good policy just in general, and, the more you can do to take advantage of the of the community that kind of rises up around,

a particular tool to to assist with documentation improvements, yeah, that's that's a good it's a good way to approach it.

So what are some specific examples of unique and interesting uses your site generators have been put to?

Well, it's funny. I just from the perspective of

the types of experiences that sometimes I have

just interacting with the web in general, I I have found interesting. So,

you know, I think I can't remember, but it was probably 2 years ago or so I

came across,

the website for the Linux kernel, which is at kernel.org,

and found that they use Pelican to publish that site. And I thought well that's that's really cool.

I know this is you know perhaps not exactly what the question was was designed to elicit but I just found it interesting that not only the the types of unique and interesting uses but also the types of organizations that use it. Like Debian,

uses it as well for their, for their new site. Chicago Linux users group. It's a translation

solution called Transifex

and they use if you go to docs.transifex.com,

you can see that they also use Polycom. So I just find that that's kind of interesting is the types of places that it shows up in the wild. In terms of unique and interesting uses,

I think 1 of the things that fascinated me was

the concept of embedding

Jupyter notebooks, which I guess used to be called IPython notebooks,

into posts so you can have, you know, actual, you know, sort of Python code in your

content that's supposed to be static. It's really interesting the types of things that you can do when you have, again going back to this concept of an extensible

ecosystem, folks will write all kinds of interesting things like the ability, if you look at the liquid tags plug in for Pelican, you'll see that it has support for a number of different things including

Jupyter Notebooks. Things like math rendering, so if you want

to talk about calculus or some other type of, you know, math

notations or or equations, you can embed those things in posts.

Barry Stein is a contributor

that's written a render math plugin that, that I think uses math jacks and,

I don't I don't have that particular use case so I'm not very well versed in it, but I think it's interesting that folks have created

these kinds of plug ins to do that.

Michael Lutzfeld wrote a a site search plugin so that you can

use JavaScript

to to search your own site. You don't have to rely on on Google or,

some of these other, you know, things that again are outside, you know, your control of your own data.

So I thought that was a really interesting

implementation. And the last thing that I'll throw out

is

and this is not really specific

to static side generators,

but it's it's interesting the types of things that you can kind of put together with them. Like, you can add interactive elements

to things that are, you know, built by static site generators. You can add contact forms. You can add, you know, subscribe me to your newsletter.

Sometimes those interactive elements are in the form of

embedded

JavaScript includes that sort of pull in that interactive component or or element from an external source,

and sometimes it can be,

a simple thing that you build yourself. For example, I wanted to have a

contact form for a variety of different things that I've done including monitor island, and so the ability to

create a single

page Python application

that you run

that accepts the input from a contact form and then passes it on either

to you via email or at, you know, or to some,

you know, other way of of tracking those those contact points. There are ways of of adding that whether you, like I said, whether you use some external,

JavaScript include or whether you write a single

page Python app that just does something as simple as

listens for the the the contact form submission. There's all kinds of ways of adding interactive elements to something that is, you know, supposed to be inherently static.

So, Roberto, how about you? What kinds of really unique things have people uses have people put, Nikola to? I have a few good ones, but he mentioned them already.

Also, I'm really jealous that you get big profile sites like Deviant and and that sort of thing. We we don't yet. I am really happy about how many

sites I see using Nicola that are

scientific

sites.

For example,

professors and student and graduate students, that sort of thing, where they need a place where they can post papers and Jupyter Notebooks

and that sort of thing,

and Nikola gives them a true to it easily. Basically, we have a Jupyter Notebook supporting core. So you set up Nikola, you throw a notebook inside it, and it will just work and appear as if it were

an HTML page. And people really like that. It it's used a lot. That was done by Damian Avila. I am really happy that he did it. There's a bunch of interesting

astronomy

and,

things I have no idea what they are because they are in fields of science that I know nothing about, like chemistry and that sort of thing. And also a lot of math,

which is something that makes me really happy because I am a frustrated mathematician.

And I'm really happy about that because it's something that is probably served by the traditional CMS

log

market, so to speak. So it makes me really happy. And also because and this is 1 advantage of SSGs that I didn't mention at the beginning of the show, which which is that the output is forever.

Once you build a site with Nicola or Pelikan or whatever,

you get the output, you put it in a website, and it's going to get picked up by the Internet,

archive, and it's going to be there forever.

So it's not going to be lost, which for science, publications,

and that sort of thing is especially important.

In fact, we have a plug in that every time you deploy something, it tells the Internet

archive to go and get it

so that it gets outside immediately.

So that's something that makes me really happy because I I have seen how much knowledge is lost

because of sites that go away. And I feel that Nicole and other SSCs do a good job of preserving that knowledge forever, and that's

that's cool.

Absolutely. I think you're right. And I think that,

organizations

like Archive Team are are a really great example of how people have come to the realization of, oh, my goodness, I've just invested

man years of time into writing posts for Postgres or whatever other

sites that large sites that just end up going away, and then you've lost everything and and File with an an a novable XML file in it, and you have to rebuild it somewhere else.

Exactly. Exactly. Yeah. That is definitely

a drag to say the least, and and that is definitely a really huge feature of of the static site generators.

So,

Nicola's flexible deployment architecture,

you know, specific example being the use of do it tasks, seems to lend itself some interesting use cases. What was the inspiration for that?

I saw do it, and my website was taking, like, an hour and a half to build.

So I said, you know what? It may be a good idea to only build the parts that are needed.

And do it is really cool software, and it does incremental rebuilds really easy. And that was the the first feature Nikola had.

Even before it could actually build websites, it could build them by pieces

and only build the part that was needed. So, basically,

I don't remember the names. Kettinos 72 is his handle on GitHub.

He's the duet author, and it's awesome.

And Nikola is actually built as a collection of of duet tasks.

Nikola doesn't cover our main, so to speak. It just creates a bunch of tasks and then do it. That's what it has to do.

And that's really cool. It it works really well. And then for deployment

and and such, we went the easy way, which is, hey. Give me a list of things to do and I will do it.

It's basically a a shell script.

That's 1 of the things that got me really interested in Nikola actually is I my use case for static site generation is actually a little bit

different from most. I don't generate the site on my development workstation and upload the output. I do infrastructure as code work and a lot of chef stuff all day. And so I actually built,

a bunch of chef recipes and cookbooks

that actually build a little, you know, droplet or or digital domain droplet

and set something up where I check my latest changes out of GitHub every, you know, 5, 10, 15 minutes. I could forget what it what it was,

and I generate my output directly on my site. So all I have to do is check my new posts into GitHub

and everything just magically appears

out there on on my site.

And I I liked the fact that with Nicola,

with with the do it idea, I could have some of that little bits of, you know, deploy machinations that are currently in Chef, I could potentially take that out of Chef and write do it tasks to make to make the deployment, you know, do the custom work that I wanted it to do. That's that's really interesting. You you can make it even easier. GitHub has webhooks. So if you run a really small service in your droplet

that only listens on 1 URL,

which is where the webhook is connected to and then launches Cola or Pelican or whatever,

Whenever there is an update on the on the report, then that also works, and you have to do nothing.

And I'll add as well that if you're using NGINX as your as your proxy server, then you can actually just write that service in embedded Lua so that you don't have to have a separate application runtime,

and you can just have it running inside of your host.

I didn't know that. Awesome.

Yeah. There's a framework called OpenResty that's built on top of that embedded Lua, and you can do all kinds of interesting things with it.

So is there any specific help that either of you would like to ask of our audience?

Themes.

Themes are always good. Yeah. People with who actually like HTML and CSS, please contact me.

Yeah. The other thing that I would add is,

you know, if folks are willing to help out just with reviewing,

issues and reviewing pull requests,

this is a very significant task. You know, anyone who's ever managed a open source project of of any, you know, moderate size

can attest to the amount of time that it takes to

stay on top of and and review the

large number

of issues and pull requests that that come in, and and that's all great. It's it's a sign of a of a vibrant community. It's a sign of a popular

project and and that's wonderful. It it's

it's, I think, disheartening

for,

you know, both the, you know, maintainers and people who perhaps come to the project for the first time to see a significant number of issues and and pull requests that that are sort of lacking attention. And to the extent that

I think that someone who's not, you know, a official maintainer may feel like, well, it's not my place

to comment on an issue or to comment on a on a pull request and and to and to provide

feedback on them, but I really couldn't disagree with that sentiment more strongly. I think that it it's it's so highly valuable,

you know, to you know, it's not just

assisting the maintainers. It's it makes the the project so much more pleasant for everyone. So to the extent that folks are willing to help out when they can, that would be much, much appreciated.

So before we move to the picks, is there anything that either of you would like to add or any questions that we didn't ask that you think we should have?

Well,

you mentioned this just kind of going back to this question of

markdown and its different variations.

I think it's interesting that, you know, this this idea that that Jeff Eywood saw this this problem and said, okay. Well, why don't we, you know, why don't we

combine our efforts and and standardize,

you know, markdown?

And the funny thing is there's, you know, there's like a there's an x kcd

comic that that talks about this. Like, you know, we need we need to have a, you know, a standard. And so someone, you know, if there's, you know, there's too many of these. There's, you know say that there's 15 different implementations,

so we need to standardize. Someone writes it's standard. Okay. Well, now you have 16 standards instead of 15. And I think that that's what CommonMark

in many ways has achieved. I don't really see it as

the markdown to rule them all. I look at it as yet another

flavor of markdown

that's really

no different than GitHub flavored markdown or multi markdown

or umpteen other different variants.

The the core

of, you know, John Gruber's original markdown and the reason why I think he's been somewhat loathed to change it is that it does

most things that someone wants to do. It doesn't mean that it does everything. It doesn't mean that there aren't ways

of improving it or extending it, but it's a good core. And I think that that's why

he's he's been content to say, like, this is this stands on its own.

And I can write

that standard markdown, you know, using links, using making making things bold, making things italic, headers, all the different sort of core components,

and feel confident that that's going to render

the same on all of these different flavors. And so really, you choose

as the person who's trying to say pick 1, you know, which 1 does the things that I want it to do. And and I just don't

I don't know that Common Mark has been successful in in unifying

markdown under a single banner, and I and I don't know that it will. And I think that that says a lot for

standardization

efforts in general. I think it's just a there's sometimes there's a reason for that fragmentation, and I don't know that

this just saying, like, there should only be 1, you know, common

markdown

is,

is very realistic.

Yeah. I mean, consider things much smaller than markdown, typography. You mentioned about

doing that sort of transformation with as your reason to join Pelican.

At at 1 point, I decided to add Typefi support to Nikola, and then there were 5 implementations.

Pelican had a fork. Then it was the original fork that was abandoned. There was another 1 for, I don't know, for

hide or whatever and

and so on.

So I contacted everybody. I said, hey, guys. Let's measure this back together. There was another the body file for for Tiago. And this is typography is really simple software. It's

5 functions,

which are basically text replacements,

and I couldn't get them all to agree.

That's funny that you mentioned,

Topography because I was the 1 that forked it.

Yeah. So, well, I I would I had been talking to Christian over time, and he, you know, he had talked about transferring the project to me. And, you know, I said that would be great. And then I think he got really busy and that didn't happen and

we needed it to do something that it didn't do. And so I eventually just said, okay. I I don't feel like I

I have a choice here. And so I I forked it and then not soon afterward, thanks to Roberto, we were able to kind of get it all under 1 banner again. And that's, you know, sometimes you have happy endings like that and sometimes Except for the angle that qualify. That they are still in public.

Right.

Right. Yeah. I I think that standardization just in general is a is a difficult thing to do. It doesn't mean that it's not worthwhile,

but there are there are times where, you know, as Roberto said, the more the more complex

the particular

thing you're trying to standardize is,

the more difficulty you're likely to have in standardizing it.

Our markdown is, like, 2 orders of magnitude of magnitude bigger than typography, so it's probably a 1000 times harder to do it.

Nobody wants to do it. That's the main problem.

I don't expect that the guys,

Haskell, that write Bandock are going to be really interested in making it fully compatible with common markup because they don't really care and so on. And nobody knows enough to

patch every markdown implementation because nobody knows how many they are. I mean,

we have Misaka, which is written in go with and so on. There's

dozens,

and they basically work.

The difference

between them is minor.

It's okay. This 1 generates paragraph inside

lists and this 1 doesn't.

Who cares?

It looks the same. Right. Yeah. If you look at the common mark plugin for Pelican, I would say that, you know,

obviously, I really don't have any way of of measuring

how widespread

adoption of it is. But if I were to just take a guess based on,

you know, mentions

in

the, you know, in the GitHub issue tracker for for Pelican,

my guess is that less than 1% of Pelican users are using CommonMark.

Yes. Sounds right. I wrote a a CommonMark plugin for Nikola. I don't think anybody used it because we have Python markdown in core. So nobody sees the need to switch to common markdown.

Thank you both.

So with that, I think we'll move into the picks. For my first pick today, I'm going to choose an Android application called Termux,

which is

an easy way to get a Linux shell environment setup without having to have root on your device or go through any

process of creating

a chroot environment.

So definitely worth taking a look at that.

My next pick is a project I came across recently called Magic Wormhole,

which is a way to securely transfer files between 2 computers

when there is

an out of band

communication happening, so a way for 2 people to share

a password that can be used for generating the 2 endpoints and then transferring files directly between the 2 computers

without necessarily being right next to each other where a USB key is infeasible.

The transfer doesn't necessarily warrant the complexity

of setting up shared dropbox folders

or any of the other various ways that we have of transferring data.

And for my last pick, I'm going to choose the Arrow library for Python,

which is a unifying wrapper around the time and datetime and timedelta libraries

and just gives it a really nice syntax for dealing with time in Python.

So, Chris, what have you got?

For my first pick, this book has been out literally since, like, the nineties. I don't forget the exact publication date, but it's just it's solo written. I'm so impressed by it that I feel like it deserves a pick. It's the Emax Lisp introduction by the f s f. It is just a really beautifully written

book that that steps you through learning how to program an emacs lisp.

It's definitely

oriented towards new programmers who don't have a ton of experience, but as somebody who's been coding for quite a number of years, I can say it was it worked pretty well for me as well. It's really great. So that's my first pick. My second pick is

3 d cellular automata in Minecraft, a first attempt. And this guy basically

took the, you know, Conway's game of life principles and implemented it as a Minecraft Java plugin.

So the results were kind of interesting. It looked like something out of a science fiction movie. Good fun.

My third and last pick

is,

Prompt 2 by Panic Software. Those guys have been around for a very long time in the Mac and iOS space, and it shows with this product. It is a

terminal emulator, basically, for your iPad or iPhone,

and it is just so polished and works so well.

It works great with an external keyboard,

and,

or even if you don't have an external keyboard, they have these sort of, like, on the go modifiable

keys to add to the extra on screen keyboard.

So if you're working in eMacs or something like that, it makes it fairly straightforward.

If not, you know, amazingly comfortable to do. It's just a beautifully polished product and and definitely worth a look if you have an iOS device and you do a lot of connecting to remote Unix boxes with SSH. And that's it for me. Justin, what do you have for us?

Well, I would be remiss if I didn't, you know, throw out shameless plugs for monitorial.net,

which is if you ever interact with any servers,

and you often wonder, like, do I have the latest security updates applied? Go there, put in your email address, and

hit the button to be notified when it launches, which hopefully will launch later on this year. And the other project as I mentioned, uprise.com, which is with 2 i's. If you go to uprise.com/join,

you can do the same for Uprise to be notified about when we're ready to launch for our concert ticket thing. Okay. Shameless plugs aside,

my actual picks are ErgoDox. I don't know if you guys are as obsessed with keyboards as I am. I, I remember using

a Apple extended

keyboard too.

But, you know, I'm I'm probably along with, with Chris, you know, I've been around long enough to have actually interacted with this this keyboard from a long long time ago and and missed the sort of feel and the impact, you know, texture, for lack of a better word, not to mention the the sounds that it that made. And so I really missed that. And so I'm just believe this, but I have 1 right in front of me right now. I'm typing.

I actually do believe it.

That's fantastic. Somewhere in the move from 1 place to another,

my my original tundra keyboard 2 got got misplaced which I'm I'm sad about. But the the good news is that, you know, I was trying to find a solution and and a solution for a particular problem that I have, which is, you know, think about how many times you hit the backspace key in a given day. Right? I mean, it's something that we hit

100 of times, you know, a a day if not, you know, thousands of times a week, and we hit it with, like, the weakest, finger on our on our hand, our our pinky.

And

so the ErgoDox is a is a way of it's sort of a it's a kit. It's not you don't really buy the finished keyboard but it kind of comes with the the printed circuit boards and the

pieces and then you solder the keys you know onto the circuit board. And so it's obviously not for the faint of heart in terms of you know you have to roll your sleeves up. But the cool thing that I like about it is is the ability to use your thumbs for more things than just hitting the space bar and and maybe, you know, modify your key. You can like, I have it mapped and you can customize every single key. You can you can make anything do any key do whatever you want it to do and,

I have it mapped so that I've got, you know, the right thumb hits space,

left thumb hits backspace,

You can do all kinds of cool things like that. So if you,

you wanna check it out it's called an Ergo docs.

I also recently got a

Jarvis bamboo

sit stand desk from Ergo Depot.

And I was I had been hunting around for a a good,

you know, mechanized,

you know, adjustable standing desk for a long time and kinda hemmed and hawed about it, and I finally just decided that that analysis paralysis was getting the better of me and and just pulled the trigger on on this particular desk. And it's I really like it. It's sturdy. It's it's really nice to look at. It's got presets so I can push 1 and have it go up to standing, push 2, have it go down to seated. I'm not sure what what I'll use 3 and 4

presets for, but so it's a great desk. You should you should check it out if you're if you're trying to improve your health. I I have sat in a chair

immobile for decades not realizing that this was not healthy,

or at least not fully realizing

the extent to which it's not healthy. So I'm I'm really glad that now I've converted to standing 90% of the time.

The other thing I'll throw at is Talkie.

Skype is useful when you need to record a call. For any other time where I'm

trying to have a conversation with someone across the interwebs,

I'll almost always reach for talkie. Io.

It's built using WebRTC.

It's built into, you know, the most recent versions of Firefox

and Chrome. I've had personally better luck with, Firefox in terms of, you know, how how reliable it is. It's not perfect. You're not gonna get, you know, maybe as good an experience as you're gonna get from a proprietary solution like Skype or or Hangouts, but you I find, like, just the idea that it's this peer to peer

web conferencing, screen sharing, video, audio that's built into the browser itself as a standard, like, that just really gets, you know, it gets me excited and it's only gonna improve over time. So you should check that out. If you guys spend a lot of time in a terminal and you haven't looked at, alternative shells,

I would recommend giving it a try. I

have been using the fish shell for a few years now

and I really dig it, and I just kind of take every opportunity I can to tell people about it because they're like, well, what is why would I use anything other than batch? And,

there's some cool things that Phish can do just out of the box. I mean, you can use, you know, ZSH and and get some similar types of

auto completion and and other, goodies out of it, but you have to make it do that. You have to configure it to do those things. Whereas out of the I find that the out of box experience with the fish shell is is just better than any shell that I've ever used.

I liked it enough that I wrote a if you go to github/justinmaier/tacklebox

you can check out a framework that I wrote for, the fish shell

that allows you to

keep, you know, custom functions and plugins and modules and and share them and and there's just certain things that I found myself

wanting to do across all the computers that I use and so I've just built something that kind of scratched my own itch. So if you find it useful, that's great. I mean, and 1 of the things that it comes with is virtual fish, which is a way of

interacting with virtual environments in in Python, in a fish context.

And I recently installed speaking of shells, I recently installed the latest 3 0 public beta of Iterm.

And I usually don't you know, when I'm talking about, you know, terminals,

usage, usually I don't go for betas of things. I like I like stability in my terminals.

But they're they added some really, really cool features, things like shell integration. You can if you have it, if you have the shell integration set up on on local and remote, you can even drag and drop files into your terminal and have it transmit that to your remote server and vice versa. And that's 1 of a dozen different cool things that this latest version of of the of iTerm does. So if you're not afraid to try a public beta of, of iTerm, you should give it a spin.

Last but not least, I'll throw out 3 just sort of lifestyle things. I'm really into craft beer.

My favorite, by far is Brother Thelonious. It is a Belgian

darkish

amberish ale.

It's just a great it's 1 of these things where I know that if I walk into a place and and I happen to have it, I know I'm gonna I know I would be happy. I know I'm gonna order that, and I'm gonna be super, super excited. I can second that. That's tasty stuff. It's really good. It's it's, yeah, just a go to favorite.

I also really like wine, and, if you ever are up in the Napa area, there's a winery called Frog's Leap.

They just make very good,

you know they have a great location in Rutherford and they just make really great, you know, what I think are reasonably

affordable wines and they're wonderful.

And very very last

is I recently went on a 2 month adventure in this past spring

in, went to Japan to visit some friends and then went to to Europe

and,

spoke at PyCon Italia. I just really met some some great people. If you have a chance to go to Italy in general, I highly recommend it. If you have the opportunity to go, you know, next spring,

for PyCon Italia, I am you'll you'll have a great time. I've I've been to several different,

you know, PyCons, both the ones in North America and regional, and

it was just a great experience that I met 2 people, in particular Flavio,

Percoco and and Alessandra Regolini who, you know, invited me to their house and had me, you know, me and my fiance stay with them.

I mean, these are people that I just met, for a matter of a couple hours.

And so we stayed with them for a number of days, and it's just it's just so great to see the Python community in, in Italy being so warm and welcoming. So shout out to all the people in in the Python community in in Italy. You guys are, you guys are doing a doing a great job keeping the Python community strong. Anyway, I will I will relinquish the mic. Apologies for my

for my long list of picks.

No worries. Roberto, what do you have for us?

Okay.

Let's see.

First thing I will my first pick is Neil Stevenson,

writer. I'm sure most people

listening to this got already heard of him.

But, you know, if you haven't, go read

some of his books. You may start with, I don't know, cryptonomicon

or something like that. Oh, yeah. Not only are they awesome, they are also really long. So you can enjoy the awesome for a long time.

Second thing,

really small Python module, which I started using a couple of weeks ago and I love, which is called docopt,

which is,

an argument parsing library.

There are no

lack of those in Python,

But this 1 is original in that you write the help, and then

it parses the the command line based on the help you wrote, which means

the help is correct, which is always nice.

And the third thing,

I was in the US last year, and sorry for this is going to be really common for you guys.

But I tried some strange food there that I like. First time I ever tried fried pickles.

I have I have had pickles. We have pickles here, but nobody has ever apparently thought of frying them, and it's a great idea.

And nothing else. Just that. Just

be happy. 0, 1 1 more thing.

Shameless plug from myself.

In Argentina, we have a Python user group, which is called PR.

Pi r p r. I don't know how to say it in English because it's not English.

We do all sorts of all sorts of events,

and we keep them all free. We have a Python, which is totally free. It's going to be in a lovely place called Mendoza later this year.

People who are interested in Python and going to the mountains

and things like that, it's a great opportunity.

Place is cheap,

and the conference is free. So pick up

a a flight over there and go to it. And in 2 weeks, there is another event that's called Pi Camp,

where about 40 of us get locked down in a hotel in the middle of nowhere with free food and free Internet and nothing else.

So usually, good stuff come

comes out of it. It's a really cool event, and I would love to see things like that in other places.

So

think about it,

and it's a lot of fun. And that's it. Sounds like a good time to me.

Yeah.

So we'd like to thank you both very, very much for for taking the time to speak with us today.

Yeah. I'd like to second those thanks. It's been a lot of fun. Very interesting and informative. I really appreciate you guys taking the time out of your day. So for anybody who wants to keep track of what you guys are up to in the Pelican and Nikola projects or get in touch with you? What would be what would be the best way for them to do that?

Sure. You can go to getpelican.com

to if you want to learn more about Pelican. I'm available at, justinmayor.com

if you want to reach out on a more personal level.

The same thing for Nicolas. Just go to getnicola.com,

and just go to the

either to the forum or the mailing list or whatever.

Just go there. Don't contact me personally because I'm probably not the right person to help you. But if you go there to a list or whatever, I will see it.

Alright. Well, thank you again very much, and I hope you both enjoy the rest of your day. Thanks for having us.

Thank you.

The Python Podcast.init

Summary

Brief Introduction

Interview

Picks

Keep In Touch

The Python Podcast.__init__

Summary

Brief Introduction

Interview

Picks

Keep In Touch

The Python Podcast.init