jartify

jartify is a small toolkit for querying a JFrog Artifactory instance from a terminal. It exposes two entry points:

Both share the same ~/.local/etc/jartify/config.yaml and $ARTIFACTORY_TOKEN env var (name is configurable).

Install

pip install jartify

Configure

Quickest: jartify-setup

jartify-setup

Prompts for URL, username, token (hidden), and the repository filter, then writes a managed export block to your .zshrc or .bashrc:

# >>> jartify setup >>>
export ARTIFACTORY_URL="..."
export ARTIFACTORY_USER="..."
export ARTIFACTORY_TOKEN="..."
export ARTIFACTORY_REPOSITORIES="all"
# <<< jartify setup <<<

ARTIFACTORY_REPOSITORIES accepts three shapes:

The legacy singular ARTIFACTORY_REPOSITORY is still read as a fallback with the same semantics.

Re-running updates the block in place (no duplicates). The rc file is chmod'd to 600 since it now contains a token. Reload with source ~/.zshrc (or open a new terminal).

Alternative: config file

Env vars take precedence, but ~/.local/etc/jartify/config.yaml works too:

artifactory:
  url: https://artifactory.example.com
  repos: ""                      # optional comma-separated allowlist

authentication:
  token_env: ARTIFACTORY_TOKEN   # name of env var holding your token
  # username: your.name          # uncomment for basic auth instead of bearer

CLI usage

# Find all requests wheels and print version / filename / sha256:
jartify 'requests-*.whl'

# Restrict to specific repos (-R is a short alias):
jartify 'myapp-*.tar.gz' -R pypi-local -R pypi-releases

# Machine-readable output:
jartify 'myapp-*.whl' --json

Output:

VERSION  FILENAME                               SHA256
-------  -------------------------------------  ----------------------------------------------------------------
2.31.0   requests-2.31.0-py3-none-any.whl       4c491f82b8a8b4...
2.32.3   requests-2.32.3-py3-none-any.whl       70761cfe03c773...

Exit codes: 0 on at least one hit, 1 on no hits, 2 on config / auth errors.

jartify-locate (offline index)

For big Artifactory instances where you want fast, repeated searches without re-hitting the server:

# One-time (or periodic) scan via AQL — stores sha256 for every file.
jartify-locate --init

# Same, but with a live progress bar (paginated AQL, 5000/page):
jartify-locate --init --status=progress

# Then search locally:
jartify-locate                       # list everything (respects --repo / --limit)
jartify-locate '*.json'              # glob
jartify-locate requests              # substring (no wildcards)
jartify-locate --fuzzy foojsn        # subsequence match
jartify-locate -R pypi-local         # all files in one repo
jartify-locate --init -R pypi-local  # refresh just one repo
jartify-locate --init --all          # scan every repo, ignoring env/config
jartify-locate --db                  # show index path + row count + last init

The index is stored at $XDG_DATA_HOME/jartify/locate.db (defaults to ~/.local/share/jartify/locate.db). --init uses one AQL request; some Artifactory instances restrict AQL to admins — if you get a 403 on --init, that's why.

Schema and append semantics. The index has two tables:

• artifacts (sha256, filename, size, created, modified) — primary key (sha256, filename). One row per unique file.
• locations (sha256, filename, repo, path) — primary key (repo, path). One row per physical copy. The same file in two repos shows up twice here but once in artifacts.

--init only ever INSERT OR REPLACEs. It never deletes, so running --init -R repo-a and then --init -R repo-b leaves you with both repos indexed. Files whose checksum was removed/renamed server-side remain in the local index until you run jartify-reset.

TUI usage

jartify-tui

Keys:

• Type a pattern → Enter runs the search.
• Ctrl+R focuses the Repo field. Comma-separate names to search multiple repos; leave blank to search all. Enter in the Repo field re-runs the last search with the new filter.
• Ctrl+F jumps back to the Search field.
• r repeats the last search, y copies the highlighted row's sha256, q quits.

Releasing

One-time: register the PyPI trusted publisher

PyPI has no API for this — the form is behind your login + 2FA. The helper script opens the right page and prints the values to type:

python scripts/register-pypi-publisher.py

It reads the project name from pyproject.toml and the GitLab namespace/repo from git remote get-url origin, so there's nothing to look up. In PyPI's "Add a new pending publisher" form, pick the GitLab tab and paste the printed values.

Each release

Push to main with a bumped version in pyproject.toml. GitLab CI runs python -m build, mints a short-lived PyPI token via OIDC trusted publishing, and uploads with twine upload --skip-existing. Pushes that do not bump the version are no-ops.