App-DocKnot

 view release on metacpan or  search on metacpan

lib/App/DocKnot.pm  view on Meta::CPAN

##############################################################################

package App::DocKnot v8.0.1;

use 5.024;
use autodie;
use warnings;

use File::BaseDir qw(config_files);
use File::ShareDir qw(module_file);
use Kwalify qw(validate);
use Path::Tiny qw(path);
use YAML::XS ();

##############################################################################
# Helper methods
##############################################################################

# Helper routine to return the path of a file from the application data.
# These data files are installed with App::DocKnot, but each file can be
# overridden by the user via files in $HOME/.config/docknot or

lib/App/DocKnot.pm  view on Meta::CPAN

    eval {
        $data_ref = YAML::XS::LoadFile($path);
        $schema_ref = YAML::XS::LoadFile($schema_path);
    };
    if ($@) {
        my $error = lcfirst($@);
        chomp($error);
        $error =~ s{ \n }{ }xms;
        die "$error\n";
    }
    eval { validate($schema_ref, $data_ref) };
    if ($@) {
        my $errors = $@;
        chomp($errors);
        die "schema validation for $path failed:\n$errors\n";
    }

    # Return the verified contents.
    return $data_ref;
}

lib/App/DocKnot/Update.pm  view on Meta::CPAN

package App::DocKnot::Update v8.0.1;

use 5.024;
use autodie;
use parent qw(App::DocKnot);
use warnings;

use Carp qw(croak);
use JSON::MaybeXS qw(JSON);
use Kwalify qw(validate);
use Path::Iterator::Rule;
use Path::Tiny qw(path);
use YAML::XS ();

# The older JSON metadata format stored text snippets in separate files in the
# file system.  This is the list of additional files to load from the metadata
# directory if they exist.  The contents of these files will be added to the
# configuration in a key of the same name.  If the key contains a slash, like
# foo/bar, it will be stored as a nested hash, as $data{foo}{bar}.
our @JSON_METADATA_FILES = qw(

lib/App/DocKnot/Update.pm  view on Meta::CPAN

            if (defined($data_ref->{vcs}{github})) {
                $data_ref->{support}{github} = $data_ref->{vcs}{github};
            }
        }
        delete $data_ref->{support}{cpan};
    }

    # Check the schema of the resulting file.
    my $schema_path = $self->appdata_path('schema/docknot.yaml');
    my $schema_ref = YAML::XS::LoadFile($schema_path);
    eval { validate($schema_ref, $data_ref) };
    if ($@) {
        my $errors = $@;
        chomp($errors);
        die "schema validation failed:\n$errors\n";
    }

    # Write the new YAML package configuration.
    YAML::XS::DumpFile($self->{output}->stringify(), $data_ref);
    return;
}

t/data/spin/input/index.th  view on Meta::CPAN

It has been said that the web is a triumph of form over content.  The
Internet equivalent of television.  The medium designed for people with
five second attention spans.  Well, anything that can only hold my
attention for five seconds, I don't want to see in the first place.  I
like words.  I don't like pointless graphics.  I don't have a burning
desire to click on everything I see.  And so, these are my web pages.

An attempt to create a triumph of content over form, if you will.

Graphics are sparse.  Text is common.  Links are present only when they
add something to the content.  All pages are validated
\link[notes/xhtml.html][XHTML], as strict as possible, with all formatting
information in style sheets, so that they will be readable on any
standards-compliant browser.  And somewhere herein is, I hope, something
that will capture your attention for more than five seconds.

Welcome.

\signature

t/data/spin/input/usefor/index.th  view on Meta::CPAN

    This is a set of best-practice guidelines for Netnews moderators
    written back in 1994.  This was intended to be published as an RFC,
    but was never completed.  Some of the advice is out of date, but much
    of this information is still relevant.
]

\desc[\link[other/pgpmoose][PGP Moose]][
    The PGP Moose protocol specifies a mechanism for signing articles
    including certain key headers so that the resulting signature can
    be used to check several key header fields and the newsgroups to which
    the article was posted.  This protocol is used primarily to validate
    approvals to moderated groups.

    This document is the original README by Greg Rose that accompanied the
    reference implementation of PGP Moose.  The canonical version is on
    \link[http://seer-grog.net/][Greg Rose's web site].
]

\desc[\link[other/pgpverify][Signing Control Messages (pgpverify)]][
    The pgpverify protocol is another protocol for signing a Usenet
    article that includes a different set of metadata and header fields

t/data/spin/output/index.html  view on Meta::CPAN

like words.  I don't like pointless graphics.  I don't have a burning
desire to click on everything I see.  And so, these are my web pages.
</p>

<p>
An attempt to create a triumph of content over form, if you will.
</p>

<p>
Graphics are sparse.  Text is common.  Links are present only when they
add something to the content.  All pages are validated
<a href="notes/xhtml.html">XHTML</a>, as strict as possible, with all formatting
information in style sheets, so that they will be readable on any
standards-compliant browser.  And somewhere herein is, I hope, something
that will capture your attention for more than five seconds.
</p>

<p>
Welcome.
</p>

t/data/spin/output/usefor/index.html  view on Meta::CPAN

    written back in 1994.  This was intended to be published as an RFC,
    but was never completed.  Some of the advice is out of date, but much
    of this information is still relevant.
</p></dd>

<dt><a href="other/pgpmoose">PGP Moose</a></dt>
<dd><p>
    The PGP Moose protocol specifies a mechanism for signing articles
    including certain key headers so that the resulting signature can
    be used to check several key header fields and the newsgroups to which
    the article was posted.  This protocol is used primarily to validate
    approvals to moderated groups.
</p>

<p>
    This document is the original README by Greg Rose that accompanied the
    reference implementation of PGP Moose.  The canonical version is on
    <a href="http://seer-grog.net/">Greg Rose's web site</a>.
</p></dd>

<dt><a href="other/pgpverify">Signing Control Messages (pgpverify)</a></dt>

t/data/spin/text/input/big-eight  view on Meta::CPAN

26. Each separate proposed change will be considered to have passed if and
    only if it received at least 100 more YES than NO votes and received
    at least twice as many YES as NO votes.

27. After the result posting, there will be a five day period when any
    objections to the vote may be raised in news.groups.  The n.a.n
    moderation team should also be informed (at newgroups-request@isc.org)
    of any objections or inaccuracies that could change the outcome.

28. At the conclusion of this waiting period, the n.a.n moderation team
    will either validate the results or will put the proposal on hold
    while objections are considered.  The final determination of whether a
    vote has passed or failed will be made by the n.a.n moderation team;
    the n.a.n moderation team may also call for a revote or take other
    appropriate action to deal with severely flawed votes.

29. The results of a vote may be accepted despite flaws in the voting
    process.  If the voting period lasted at least 21 days with at least
    one posted CFV and the flaws are, in the determination of the n.a.n
    moderator, extremely unlikely to have caused a change in the outcome,
    the n.a.n moderator may accept the voting results even if the above

t/data/spin/text/output/big-eight.html  view on Meta::CPAN

    After the result posting, there will be a five day period when any
    objections to the vote may be raised in news.groups.  The n.a.n
    moderation team should also be informed (at newgroups-request@isc.org)
    of any objections or inaccuracies that could change the outcome.
</p>
</li>

<li value="28">
<p>
    At the conclusion of this waiting period, the n.a.n moderation team
    will either validate the results or will put the proposal on hold
    while objections are considered.  The final determination of whether a
    vote has passed or failed will be made by the n.a.n moderation team;
    the n.a.n moderation team may also call for a revote or take other
    appropriate action to deal with severely flawed votes.
</p>
</li>

<li value="29">
<p>
    The results of a vote may be accepted despite flaws in the voting

t/metadata/licenses.t  view on Meta::CPAN

#
# Copyright 2017-2018, 2020-2021 Russ Allbery <rra@cpan.org>
#
# SPDX-License-Identifier: MIT

use 5.024;
use autodie;
use warnings;

use File::ShareDir qw(module_file);
use Kwalify qw(validate);
use Test::More tests => 2;
use YAML::XS ();

# Isolate from the environment.
local $ENV{XDG_CONFIG_HOME} = '/nonexistent';
local $ENV{XDG_CONFIG_DIRS} = '/nonexistent';

# Load the module.
BEGIN { use_ok('App::DocKnot') }

# Check the schema of the licenses.yaml file.
my $licenses_path = module_file('App::DocKnot', 'licenses.yaml');
my $licenses_ref = YAML::XS::LoadFile($licenses_path);
my $schema_path = module_file('App::DocKnot', 'schema/licenses.yaml');
my $schema_ref = YAML::XS::LoadFile($schema_path);
eval { validate($schema_ref, $licenses_ref) };
is($@, q{}, 'licenses.yaml fails schema validation');