view release on metacpan or  search on metacpan

README.md  view on Meta::CPAN

# DocKnot

[![Build
status](https://github.com/rra/docknot/workflows/build/badge.svg)](https://github.com/rra/docknot/actions)
[![CPAN
version](https://img.shields.io/cpan/v/App-DocKnot)](https://metacpan.org/release/App-DocKnot)
[![License](https://img.shields.io/cpan/l/App-DocKnot)](https://github.com/rra/docknot/blob/master/LICENSE)
[![Debian
package](https://img.shields.io/debian/v/docknot/unstable)](https://tracker.debian.org/pkg/docknot)

Copyright 1999-2024 Russ Allbery <rra@cpan.org>.  This software is
distributed under a BSD-style license.  Please see the section
[License](#license) below for more information.

## Blurb

DocKnot is a static web site generator built around a macro language
called thread, with special support for managing software releases.  In
addition to building a web site, it can generate distribution tarballs and
consistent human-readable software package documentation from a YAML
metadata file and templates.  The goal is to generate both web pages and
distributed documentation files (such as `README`) from the same source,
using templates for consistency across multiple packages.

## Description

In 1999, I wrote a program named `spin` that implemented an idiosyncratic
macro language called thread.  It slowly expanded into a static web site
generator and gained additional features to manage the journal entries,
book reviews, RSS feeds, and software releases.  DocKnot is the latest
incarnation.

In addition to its static web site generator, DocKnot can use one metadata
file as its source information and generate all the various bits of
documentation for a software package.  This allows me to make any changes
in one place and then regenerate the web page, included documentation, and
other files to incorporate those changes.  It also lets me make changes to
the templates to improve shared wording and push that out to every package
I maintain without having to remember track those changes in each package.

DocKnot is also slowly absorbing other tools that I use for software
distribution and web site maintenance, such as generating distribution
tarballs for software packages.

DocKnot was designed and written for my personal needs, and I'm not sure
it will be useful for anyone else.  At the least, the template files are
rather specific to my preferences about how to write package
documentation, and the thread macro language is highly specialized for my
personal web site.  I'm not sure if I'll have the time to make it a more
general tool.  But you're certainly welcome to use it if you find it
useful, send pull requests to make it more general, or take ideas from it
for your own purposes.

## Requirements

Perl 5.24 or later and Module::Build are required to build this module.
The following additional Perl modules are required to use it:

* Date::Language (part of TimeDate)
* Date::Parse (part of TimeDate)
* File::BaseDir
* File::ShareDir
* Git::Repository
* Image::Size
* IO::Compress::Xz (part of IO-Compress-Lzma)
* IO::Uncompress::Gunzip (part of IO-Compress)
* IPC::Run
* IPC::System::Simple
* JSON::MaybeXS 1.004000 or later
* Kwalify
* List::SomeUtils 0.07 or later
* Path::Iterator::Rule
* Path::Tiny 0.101 or later
* Perl6::Slurp
* Pod::Thread 3.01 or later
* Sort::Versions
* Template (part of Template Toolkit)
* YAML::XS 0.81 or later

## Building and Installation

DocKnot uses Module::Build and can be installed using the same process as
any other Module::Build module:

```
    perl Build.PL
    ./Build
    ./Build install
```

You will have to run the last command as root unless you're installing
into a local Perl module tree in your home directory.

## Testing

DocKnot comes with a test suite, which you can run after building with:

```
    ./Build test
```

If a test fails, you can run a single test with verbose output via:

```
    ./Build test --test_files <path-to-test>
```

Capture::Tiny and File::Copy::Recursive are required to run the test