Extension of Python REST API (repo index, metrics, content filters)
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 49
- Forks
- 88
- Avg merge
- 1d 10h
- Merged PRs (30d)
- 31
Description
Lightwell UI lists Python packages, versions, and repository counts through content-sources-backend. That backend reads Pulp Postgres directly (Tangy). We need Pulp HTTP APIs so the path is UI → backend → Pulp REST, not SQL.
Today GET …/content/python/packages/ is one row per file (wheel + sdist). It cannot paginate distinct package names or return versions per package.
{pk} is the repository UUID. Latest complete repository version is implied.
| UI path | Pulp |
|---|---|
| PackageList | New GET …/repositories/python/python/{pk}/packages/ — one row per name_normalized, paginate, name_normalized__istartswith |
| PackageVersions | Extend existing GET …/content/python/packages/ with collapse_builds=true and serializer field base_version (still use packagetype=sdist) |
| PackageGet | Existing content list (name + version + packagetype=sdist); add base_version on the serializer. Omit collapse_builds. |
| RepoMetrics | New GET …/repositories/python/python/{pk}/metrics/ — package_count, version_count, build_count |
collapse_builds=true (default false): strip trailing \.[a-zA-Z]+-\d+$ from version, one row per (name_normalized, base_version).
PackageList rows: name, name_normalized, versions[], latest_releases[] (version, created_at, release). Same version keys in both lists. Pulp-native shape, not Tangy DTOs.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the existing GET …/content/python/packages/ endpoint and its serializer, then locate the repository package and metrics API entry points described in the issue. Done means the new and extended Pulp REST responses support the specified pagination, filters, collapse behavior, fields, and package/version/build counts without relying on Tangy DTOs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgresql, python
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100