Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

generate_repo_overview: show dependency freshness and reverse dependencies on detail pages

Aperta
  • Qualcosa non va?
#125 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
15/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github, python
Ambito
tooling

Direzione di ricerca

Start with the generate_repo_overview code that builds the collected snapshot and the detail-page generator, and find where dependency declarations and module-to-repository mappings are gathered; the baselibs page linked in the issue shows the current "HEAD vs. Release" section. Done means the snapshot carries release and default-branch freshness plus reverse dependencies, and the static detail pages render them with explicit unknown states. This spans snapshot collection, resolution against other repositories, and rendering, so coordinate scope with maintainers (see #123 and #85) before starting.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Why

Repository detail pages should make it easy to answer two questions: “Are this repository's dependencies up to date?” and “Which repositories consume this repository, and at which version?” This helps maintainers plan dependency updates and understand the impact of a new release or change.

For example, https://eclipse-score.github.io/.github/baselibs/index.html currently lists dependencies under “Dependencies: HEAD vs. Release”. That compares the dependency declarations in baselibs' own default branch and latest release; it does not show whether newer versions of those dependencies are available or provide a reverse dependency view.

Expected behavior

Dependencies used by this repository

Extend the detail page with dependency information showing:

  • Dependency/module name and a link to its source repository and detail page where available.
  • The version or commit actually used, including effective Git overrides where applicable.
  • The dependency's latest available release and whether it is newer than the version used.
  • Whether the dependency's default branch contains newer commits than the consumed revision, ideally including a commits-behind count and a comparison link where the revisions can be resolved.
  • Separate release freshness from default-branch freshness: using the latest release can still mean there are newer commits on the default branch.
  • Explicit unknown/unavailable states when a source repository or revision cannot be resolved. Diverged history and non-comparable versions must not be presented as “up to date”.
Repositories using this repository

Add a “Used by” section listing consumers found within the collected repository set:

  • Consumer repository, linked to its detail page.
  • The version or commit of this repository used by that consumer.
  • The consumer ref/context the dependency was read from, clearly distinguishing its default branch and latest release where both are available.

The list should make its collection scope clear; it cannot imply that repositories outside the collected set have been searched.

Implementation considerations

  • Build forward and reverse dependency relationships from the collected dependency declarations and module-to-repository mappings, rather than limiting the view to the small configured list of tracked dependencies.
  • Resolve release versions and commit pins against the dependency's own repository and default branch. Preserve the distinction between module/registry versions and GitHub release tags.
  • Collect the required metadata into the snapshot so the generated static detail pages work without live API calls.
  • Keep repository identities unambiguous across organizations (see #123).

Acceptance criteria

  • A dependency pinned to an older release shows the used version and the newer available release.
  • A dependency using its latest release can independently show newer commits on its default branch.
  • A Git-pinned dependency is compared using its effective commit rather than an overridden version declaration.
  • If repository A uses repository B, B's detail page lists A and the exact version or commit A consumes.
  • Multiple consumers using different versions remain distinguishable, and unresolved comparisons are clearly marked.

Related: #85 mentions collecting dependency relationships and a list of repository users; this issue specifies the detail-page behavior and freshness information.

Lingua principale
Python
Stelle
0
Fork
14
Merge medio
19h 31m
PR unite (30g)
11

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di eclipse-score/.github

Tutte le issue di eclipse-score/.github

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.