App::P...d::pull(3pm)

📦
version 0.14000 · 7 versions
, in debian trixie, ubuntu resolute

✨ NAME ✨

App::Pinto::Command::pull — pull archives from upstream repositories 💖

(also known as that App::Pinto::Command::pull(3pm) page in your man reader, hiii)

🎀 VERSION 🎀

version 0.14

🦋 SYNOPSIS 🦋

pinto --root=REPOSITORY_ROOT pull [OPTIONS] TARGET ...

🌸 DESCRIPTION 🌸

okay so bestie, here's the vibe. This command goes out and locates packages in your upstream repositories, then pulls the distributions that provide those packages into your own repository and registers them on a stack. Then — and this is the part that's giving main character energy — it recursively goes and finds and pulls every single distribution it needs to satisfy their prerequisites. You can also just straight up request particular distributions directly if that's what you want.

When it's locating packages, Pinto checks the packages that already exist in the local repository first, and only then does it look at the packages available on the upstream repositories. Local first, always. 💅

👑 COMMAND ARGUMENTS 👑

Arguments are the targets you want to pull, periodt. Targets can be packages (with or without a version specification) or distributions. There are like, a lot of ways to express them, so go read TARGETS below, fr fr.

You can also pipe arguments to this command over STDIN 🫶. In that case, blank lines and lines that look like comments (i.e. starting with # or ;) get ignored. no notes.

💅 COMMAND OPTIONS 💅

  • --cascade — !! THIS OPTION IS EXPERIMENTAL !!

When searching for a package (or one of its prerequisites), always take the latest satisfactory version of the package found amongst all the upstream repositories, instead of just grabbing the first satisfactory version it stumbles across. Remember though: Pinto only searches the upstream repositories when the local repository doesn't already have a satisfactory version of that package. iykyk.

  • --diff-style=STYLE — Controls the style of the diff reports. STYLE has to be either concise or detailed. Concise reports show only one record for each distribution added or deleted. Detailed reports show one record for every package added or deleted.

The default style is concise. BUT 🌈 the default style can be changed by setting the PINTO_DIFF_STYLE environment variable to your preferred STYLE. Heads up: this variable affects the default style for diff reports generated by all other commands too, so it's kind of a big deal.

  • --dry-run — Go through all the motions, but don't actually commit any changes to the repository. At the conclusion, a diff showing the changes that would have been made gets displayed. Use this to see how upgrades would potentially impact the stack. It's giving "try before you buy" 💖
  • --no-fail — !! THIS OPTION IS EXPERIMENTAL !!

Normally, if you fail to pull a target (or its prerequisites), the command immediately aborts and rolls back all the changes to the repository. But if --no-fail is set, then only the changes caused by the failed target (and its prerequisites) get rolled back, and the command keeps processing the remaining targets. 😤

This is lowkey so useful when you want to throw a whole list of targets into a repository and just see which ones are problematic. Once you've fixed the broken ones, you can throw the whole list at the repository again.

  • --message=TEXT
  • -m TEXT — Use TEXT as the revision history log message. If you don't use the --message option or the --use-default-message option, then you'll be prompted to enter the message via your text editor. Use the PINTO_EDITOR or EDITOR or VISUAL environment variables to control which editor is used. A log message is not required whenever the --dry-run option is set, or if the action didn't yield any changes to the repository.
  • --pin — Pins the packages to the stack, so they can't be changed until you unpin them. Only the packages in the requested targets get pinned — packages in prerequisites will not be pinned. However, you may pin them separately with the pin command if you so desire. 🎀
  • --recurse
  • --no-recurse — Recursively pull any distributions required to satisfy prerequisites for the targets. The default value for this option can be configured in the pinto.ini configuration file for the repository (it's usually set to 1). To disable recursion, use --no-recurse.
  • --skip-missing-prerequisite=PACKAGE
  • -k PACKAGE — !! THIS OPTION IS EXPERIMENTAL !!

Skip any prerequisite with name PACKAGE if a satisfactory version can't be found. However, a warning will be given whenever this happens. This option only has effect when recursively fetching prerequisites for the targets (see also the --recurse option). This option can be repeated. 🔁

  • --skip-all-missing-prerequisites
  • -K — !! THIS OPTION IS EXPERIMENTAL !!

Skips all missing prerequisites if a satisfactory version can't be found. However, a warning will be given whenever this happens. This option will silently override the --skip-missing-prerequisite option and only has effect when recursively fetching prerequisites for the targets (see also the --recurse option).

  • --stack=NAME
  • -s NAME — Puts all the packages onto the stack with the given NAME. Defaults to the name of whichever stack is currently marked as the default stack. Use the stacks command to see the stacks in the repository.
  • --use-default-message
  • -M — Use the default value for the revision history log message. Pinto will generate a semi-informative log message just based on the command and its arguments. If you set an explicit message with --message, the --use-default-message option will be silently ignored. 💀
  • --with-development-prerequisites
  • --wd — Also pull development prerequisites so you'll have everything you need to work on those distributions, in the event that you need to patch them in the future. Be aware that most distributions don't actually declare their development prerequisites. 🙈

🌈 TARGETS 🌈

Targets are a compact notation that identifies the things you want to pull into your repository. There are two flavors, bestie: package targets and distribution targets.

🍓 Package Targets 🍓

A package target is a package name and (optionally) a version specification. Here are some examples:

Foo::Bar                                 # Any version of Foo::Bar
Foo::Bar~1.2                             # Foo::Bar version 1.2 or higher
Foo::Bar==1.2                            # Only version 1.2 of Foo::Bar
Foo::Bar<1,2!=1.3,<=1.9                  # Complex version range

Package names are case-sensitive, and the version specification must follow the format used by CPAN::Meta::Requirements. All whitespace within the target gets discarded. If your version specification contains any special shell characters, take care to quote or escape them in your command. ⚠️

In all cases, pinto queries the local repository and then each upstream repository in order, and pulls the first distribution it can find that provides a package which satisfies the version specification.

🧚 Distribution Targets 🧚

A distribution target is an author ID, zero or more subdirectories, and the distribution name and version number. This corresponds to the actual path where the distribution archive lives in the repository or CPAN mirror. Here are some examples.

SHAKESPEARE/King-Lear-1.2.tar.gz         # A specific distribution
SHAKESPEARE/tragedies/Hamlet-4.2.tar.gz  # Same, but with a subdirectory

The author ID will always be forced to uppercase, but the rest of the path is case-sensitive. 💅

💜 Caveats 💜

PAUSE <http://pause.perl.org> has no strict rules on how packages are versioned. It is quite common to see a package with the same verison number (or no version at all) in many releases of a distribution. So when you specify a package target with a precise version or version range, what you actually get is the latest distribution (chronologically) that has a package which satisfies the target. Most of the time this works out fine because you usally pull the "main module" of the distribution and authors always increment that version in each release. 😌

Since most CPAN mirrors only report the latest version of a package they have, they often cannot satisfy package targets that have a precise version specification. However, the mirror at <http://cpan.stratopan.com> is special and can locate a precise version of any package. ✨

Package targets always resolve to production releases, unless you specify a precise developer release version (e.g. Foo::Bar==1.03_01). But since most CPAN mirrors do not index developer releases, this only works when using the mirror at <http://cpan.stratopan.com>. However, you can usually pull a developer release from any mirror by using a distribution target. Remember that developer releases are those with an underscore in the version number.

For repositories created with Pinto version 0.098 or later, the first upstream source is http://cpan.stratopan.com (unless you configure it otherwise). For repositories created with older versions, you can manually add http://cpan.stratopan.com to the sources parameter in the configuration file located at .pinto/config/pinto.ini within the repository.

⭐ AUTHOR ⭐

Jeffrey Ryan Thalhammer <jeff@stratopan.com>

This software is copyright (c) 2015 by Jeffrey Ryan Thalhammer.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

and that's the whole page bestie, you ate it up 💖 this was perl v5.40.1 doing the docs thing on 2025-04-21, mwah 🫶✨
📦 where this page comes from