From Pulp
Pulp is a content-management platform whose
pulp_python plugin is, feature for feature, velodex's closest living relative:
lazy (on_demand) mirroring of PyPI subsets, pull-through caching, uploads, curation with allow/deny lists, and
versioned repository snapshots. The difference is the machinery: a Pulp deployment is a Django REST API, a separate
content-serving app, one or more task workers, and PostgreSQL
(architecture), and Pulp also manages RPMs,
containers, and other content types with the same model.
Why velodex
If Python packages are the only content type you need, the platform is the overhead: four services and a database
against one binary and a data directory. velodex also serves at a plain index root instead of
/pypi/{base_path}/simple/, and its pull-through composes: virtual indexes can layer cached indexes of cached indexes,
where Pulp documents that
chaining pull-through indices does not work.
The renames
| Pulp (pulp_python) | velodex |
|---|---|
| repository + remote + distribution | one [[index]] entry |
policy = "on_demand" remote | the cached default |
| pull-through cache on a distribution | a cached layer in a virtual index |
| includes/excludes curation | shadowing plus yank and hide overrides |
…/pypi/{base_path}/simple/ | /{route}/simple/ |
pulp python content upload / twine | twine / uv publish, unchanged |
| repository version rollback | not offered; deletes are the undo |
Pitfalls
- Pulp's versioned snapshots ("repoint the distribution at yesterday's repository version") have no velodex counterpart; if you rely on them for staged promotion, keep Pulp for that flow.
- Multi-tenancy via domains, RBAC, and the task queue are platform features velodex does not replicate.
- S3/Azure/GCS artifact storage is Pulp-native; velodex stores on local disk.