Alien-Libgit2

 view release on metacpan or  search on metacpan

.claude/agents/alien-libgit2-worker.md  view on Meta::CPAN

Coordinate work via `karr`: pick tickets from the local board, and record drift
you find as new tickets rather than expanding scope mid-change.

## What lives in this agent (and in no skill)

- **Single repo, single distribution.** No family coordination here. Work that
  belongs to `Git::Libgit2` or `Git::Native` becomes a ticket on *that* repo's
  board (`~/dev/p5-git-libgit2`, `~/dev/p5-git-native`) — never an edit there.
- **The decisions live in `alienfile`, not in Perl.** `lib/Alien/Libgit2.pm`
  stays `use parent 'Alien::Base'` + `$VERSION` + POD. If a change wants a
  method there, say why before writing it.
- **`.claude/` is git-ignored except for a whitelist** in `.gitignore`
  (`settings.json`, `agents/`, `skills/`, `rules/`, `hooks/`). A new directory
  under `.claude/` is invisible to git until it is whitelisted there — check
  `git status --short` after adding one, not just the file listing.
- **Skill files under `.claude/skills/` are hardlinks** to `~/dev/skills/…`.
  Editing one with `Edit`/`Write` detaches the inode and silently forks every
  other repo's copy; rewrite in place (`cat > path <<'EOF'`) instead. The
  project-owned `alien-libgit2-core` has no link yet — normal edits are fine
  there.

.claude/skills/alien-libgit2-core/SKILL.md  view on Meta::CPAN

skill `perl-alien` — this file holds only what is true about *this* distribution.

## What the distribution is

One job: make a libgit2 >= 1.9.3 available to Perl, over two paths.

- **system** — `plugin 'PkgConfig' => (pkg_name => 'libgit2', minimum_version => '1.9.3')`.
- **share** — CMake build of `share/libgit2-1.9.3.tar.gz`, no network
  (`Fetch::Local` + a `file://` `start_url` built with `Path::Tiny->cwd`).

`lib/Alien/Libgit2.pm` is deliberately logic-free: `use parent 'Alien::Base'`,
`$VERSION`, POD. Everything that decides anything is in `alienfile`. Consumers
get `dynamic_libs` (FFI) or `cflags`/`libs` (XS) from `Alien::Base` — do not add
methods here to "help" them.

The share build's CMake flags are load-bearing: `USE_SSH=ON`,
`USE_HTTPS=OpenSSL`, `REGEX_BACKEND=builtin` (builtin so a system PCRE cannot
change matching behaviour at runtime), plus `BUILD_TESTS/CLAR/EXAMPLES=OFF`.
Anything that builds libgit2 elsewhere — the CI system job included — uses the
same flag set, or the two paths stop being comparable.

.claude/skills/getty-perl-core/SKILL.md  view on Meta::CPAN

- **Scripts, tests, plain modules:** `use strict; use warnings;` explicitly.
- **Classes:** `Moo`, `Moose`, `Catalyst` and anything derived from them enable both on import — do not repeat them there.

The rule is "always on", never "leave them out". Omitting them from a class is correct only because the object system already did it.

## Object system

- **One object system per distribution.** Pick Moo or Moose and use it everywhere; mixing is for boundaries a framework forces (e.g. RapidApp), not a choice.
- **`is => 'ro'` is the default.** `rw` is the exception and needs a reason.
- **`lazy_build => 1` + `sub _build_foo`** over `default => sub { ... }` for anything non-trivial.
- **`weak_ref => 1`** on attributes holding a reference back to a parent/owner — standard for nested object graphs, prevents circular refs.
- **`namespace::autoclean`** on every class file. Classes extending DBIx::Class (`MooseX::NonMoose`) use **`MooseX::MarkAsMethods autoclean => 1`** instead.
- **`no Moose;` + `__PACKAGE__->meta->make_immutable;`** at the bottom of every Moose class.
- **Types:** the tendency is to type what arrives from outside — Moose's own constraints where Moose is already there, `Types::Standard` where it is not. Not every distribution needs a type system, and none needs one for every field: `getty-perl-ty...

## Singletons

- **`->instance`** for `MooseX::Singleton` / `MooX::Singleton` classes. Never `->new` on a singleton.
- **`->new`** for everything else.

## Subroutines

.claude/skills/kanban-issues-karr-cli/SKILL.md  view on Meta::CPAN

### Delete task

```bash
karr delete ID                               # asks first
karr delete ID --yes                         # skip confirmation
karr delete ID,ID,ID --yes                   # a batch
```

Before an id goes, `delete` names on STDERR every card on this board that
points at it -- a `depends_on` entry or a `parent` -- and every cross-board
link the card itself carries (`escalated-from:`, `needs:`), offering
`karr archive` as the way to keep the card readable instead. The delete then
proceeds: karr warns about dependencies, it does not block on them. `--json`
carries the same sentences as `dependent_warnings` and `cross_board_warnings`
in the result object.

The question itself goes to STDERR on every path, not only under `--json`:
STDOUT belongs to the result, so `karr delete ID --json` decodes as a whole
even when the answer is typed rather than passed as `--yes`. A task with a live
claim is not deleted at all -- release it or wait for `claim_timeout`.

.claude/skills/perl-alien/SKILL.md  view on Meta::CPAN

# Alien — providing a C library to CPAN

An `Alien::Foo` distribution answers one question at install time: **is a usable
libfoo already here, and if not, how is one built?** Everything downstream — the XS
module that links against it, the FFI module that dlopens it — asks the resulting
class for flags and never repeats that logic.

Two halves, both small:

- The **`alienfile`** in the distribution root describes probing and building.
- **`lib/Alien/Foo.pm`** is `use parent 'Alien::Base';` plus POD. There is no logic
  to write there — `Alien::Base` supplies `cflags`, `libs`, `dynamic_libs`,
  `bin_dir`, `version`, `runtime_prop`.

Build details, properties and the plugin catalogue:
[references/alienfile.md](references/alienfile.md).
The XS/FFI side, `cpanfile`, and `Test::Alien`:
[references/consuming-and-testing.md](references/consuming-and-testing.md).

## The shape

CLAUDE.md  view on Meta::CPAN

Two install paths, decided at install time: a system libgit2 found by
`pkg-config libgit2` (>= 1.9.3), or a CMake build of the bundled source tarball. The
share build needs no network — suitable for air-gapped installs.

## Layout

| Path | Holds |
|---|---|
| `alienfile` | every decision: the `PkgConfig` probe and the CMake share build |
| `share/libgit2-1.9.3.tar.gz` | the bundled source, exactly one tarball |
| `lib/Alien/Libgit2.pm` | `use parent 'Alien::Base'` + `$VERSION` + POD, no logic |
| `t/01-alien.t` | `alien_ok` + `ffi_ok` on `git_libgit2_init` / `_shutdown` / `_version` |
| `.github/workflows/` | four jobs — system and share, on linux and macOS |

Packaging is `[@Author::GETTY]` with `alien_build = 1`. `dzil test` covers whichever path
the probe lands on here, so anything touching the build runs both explicitly:

```bash
env ALIEN_INSTALL_TYPE=share  dzil test
env ALIEN_INSTALL_TYPE=system dzil test
```

lib/Alien/Libgit2.pm  view on Meta::CPAN

# ABSTRACT: Find or build libgit2, the linkable Git library

package Alien::Libgit2;
our $VERSION = '0.002';
use strict;
use warnings;
use parent 'Alien::Base';

1;

__END__

=pod

=encoding UTF-8

=head1 NAME