Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide the necessary libraries for a simple static site generator #597

Closed
5 tasks done
yorickpeterse opened this issue Jul 22, 2023 · 5 comments
Closed
5 tasks done
Assignees
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers feature New things to add to Inko, such as a new standard library module

Comments

@yorickpeterse
Copy link
Collaborator

yorickpeterse commented Jul 22, 2023

Both my personal website and the Inko website use Middleman and Ruby for generating the websites. I would like to move this over to an Inko based solution for the following reasons:

  1. Middleman has been more or less on life support for several years now, and hasn't really seen active development in recent years. Based on the experience we had using it for GitLab's website, it's also quite slow for larger websites.
  2. To eat our own dog food
  3. This will need a variety of libraries useful in other scenarios, making Inko more attractive

There are quite a few components involved that we'll need to provide, either built into the standard library, or as a third-party library. We'll start with providing everything as a third-party library, then we can investigate pulling certain libraries into the standard library (where/if this makes sense).

Necessary libraries

  • Generating XML/HTML for Atom/RSS feeds, templates, etc
  • Markdown parsing, with support for the pipe tables extension (i.e. a superset of Commonmark, because it doesn't have pipe tables), and support for custom processing of the AST (so we can implement e.g. a table of contents generator).
    • I thought about switching to Djot instead, but Vale has no support for it, so it would probably get super confused at some point. Also, basically nobody is using Djot at this point.
    • We could probably shell out to Pandoc at first, though it's not an ideal (and certainly not a long-term) solution
    • We also need a way of encoding front matter/meta data, preferably without the need for YAML, because I'm not writing a YAML parser
    • Done: https://github.com/yorickpeterse/inko-markdown
  • [ ] An HTTP(s) client. Since Support for TLS sockets #329 will take a while, this would probably have to be done using CURL. An HTTP client is needed for the Inko website, so we can pull repository information such as tags for the package list. We currently use the GraphQL API, but it's not that great, so I'm fine switching to the REST API.
    • We'll just continue to use the Ruby scripts for the time being.
  • An actual static site generator that ties it all together. I want something a bit more low-level that gives you control over things, instead of forcing you to do things a specific way (i.e. like Hugo and many others). Basically it should provide various building blocks, but you glue them together yourself.
  • A command line arguments parser in the style of rust-lang/getopts. This is a bit more verbose compared to those that generate everything for you (e.g. based on a help string), but gives you full control. You can always build something more high-level on top of it. This should go in the standard library (hence the more low-level nature).
  • [ ] A library for printing ANSI escape sequences, automatically disabling them if there's no TTY (i.e. in a pipe context). This isn't required, but allows for nicer looking error messages.
  • A syntax highlighting library

There's probably more, but this is what I can think of at the moment.

@yorickpeterse yorickpeterse added accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers feature New things to add to Inko, such as a new standard library module labels Jul 22, 2023
@yorickpeterse
Copy link
Collaborator Author

Come to think of it: since Djot is mostly compatible with Markdown, I think it should be fine to use Djot instead of Markdown; at least Djot should be easier to parse.

@yorickpeterse
Copy link
Collaborator Author

Regarding markup: I looked into Djot, but it's equally annoying to parse. I started working on a Markdown-like language at https://github.com/yorickpeterse/inko-markdown/tree/parser. I'm aiming to keep it as close as possible to Markdown, but it does differ in a few places. It will probably take a while for this to be complete, and I've yet to come up with a better name.

@yorickpeterse
Copy link
Collaborator Author

For syntax highlighting:

My personal website uses the following languages for code snippets:

  • bash
  • fish
  • inko
  • make
  • perl
  • ruby
  • rust
  • toml

The Inko website uses the following:

  • bash
  • c
  • inko
  • ruby
  • rust

This means we'll need to have somewhat capable syntax highlighting for these languages.

@yorickpeterse
Copy link
Collaborator Author

inko-syntax now supports the necessary languages. The setup as a whole could be improved a lot, but it's good enough for our static site generation needs. The next step is to write the actual static site generator.

@yorickpeterse yorickpeterse self-assigned this Oct 28, 2023
@yorickpeterse
Copy link
Collaborator Author

With https://github.com/yorickpeterse/inko-wobsite released and in use for my personal website, this can be closed. In the coming weeks I'll start porting the Inko website to inko-wobsite. I'd also like to port over the documentation instead of using mkdocs, but that may take a little longer as I'd like to retain a search function of sorts for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepting contributions Issues that are suitable to be worked on by anybody, not just maintainers feature New things to add to Inko, such as a new standard library module
Projects
None yet
Development

No branches or pull requests

1 participant