Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

generate_repo_overview: show dependency freshness and reverse dependencies on detail pages

Abierto
  • ¿Algo no está bien?
#125 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
15/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github, python
Área
tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
0
Forks
14
Merge medio
19 h 31 min
PR fusionados (30 d)
11

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de eclipse-score/.github

Todos los issues de eclipse-score/.github

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.