Migrating from Poulpy

Poulpy is deprecated and unmaintained. It still works from time to time, but nothing is done anymore when a Forge service changes under it, so it will keep breaking. The Forge CLI replaces it.

The two tools are not built the same way. Poulpy was a thin, auto-updated wrapper that exposed every endpoint of every Forge service (through Restish), plus a pipeline and preset system to glue those calls together (through Nushell). The Forge CLI instead ships a fixed set of commands for the things people actually did with those pipelines — downloading traces, listing groups, building reports — and does the glue itself, in Python.

Practically: what used to be a preset is now a command, and what used to be a raw endpoint call is now forge auth token plus your own curl.

Command mapping

Poulpy	Forge CLI
poulpy auth	forge auth token
poulpy download_traces --submission_definition_uri <uri>	forge activities submissions download-traces <uri>
poulpy pipe 'operator get-picked-submission <uri> ...'	forge activities submissions download-traces <uri>
poulpy operator ... (raw endpoint calls)	No equivalent, see Calling the APIs by hand
poulpy pipe '...' (Nushell pipelines)	No equivalent, see Replacing pipelines and presets
poulpy intranet tenant-validate / tenant-deploy	No equivalent, see Deploying activities and tenants
poulpy intranet pacv2-validate / pacv2-deploy	No equivalent, see Deploying activities and tenants
poulpy refresh	Not needed, the CLI has no generated configuration

The Forge CLI also does a number of things Poulpy never did, among others listing and cloning groups, generating validation and success reports and rerunning moulinettes. See the command reference.

Other differences to be aware of

Installation and updates

Poulpy was installed from the GitLab package registry with pip and updated itself. The Forge CLI is installed from its repository and does not update itself: git pull && uv sync is now part of your routine. See Installation.

Credentials

Tokens move from ~/.cri-tokens to ~/.config/forge-cli-credentials.json, and the JSON keys change. A script reading the old file needs to be updated:

# Before
cat ~/.cri-tokens | jq -r .idToken
# After, and preferably
forge auth token

Login messages go to stdout

Poulpy printed its login instructions on stderr, so $(poulpy auth) kept working even when it had to log you in first. The Forge CLI prints them on stdout. Run forge auth token once interactively after installing, and your command substitutions will keep getting a clean token afterwards.

No external dependencies

The Forge CLI does not need Restish or Nushell. If you installed them only for Poulpy, you can get rid of them.

Calling the APIs by hand

Poulpy mirrored the whole Swagger of each service. The Forge CLI does not; it only authenticates you. For endpoints with no dedicated command, get a token and call the API directly:

curl --fail -H "Authorization: Bearer $(forge auth token)" \
  https://operator.forge.epita.fr/api/activities

The Operator Swagger lists what is available.

Replacing pipelines and presets

A poulpy pipe '...' pipeline usually becomes either a single Forge CLI command (most of the common ones were turned into commands) or a small shell script around forge auth token and curl. Because the output of the CLI is plain JSON or CSV on demand, jq is enough to chain things:

forge activities list --json | jq -r '.[] | select(.tenantSlug == "my-tenant") | .uri'

If you had a preset that you cannot rebuild this way, tell us on the CLI repository: commands worth having are added there.

Deploying activities and tenants

Poulpy could validate and deploy activity.yml and tenant.yml files by hand. The Forge CLI has no equivalent yet, and deployment is done by the GitLab CI pipeline of your repository. See Deploy Projects and the tenant configuration reference.

If your pipeline fails, read the job logs: they contain the validation errors raised by the deployment job.