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

`dependsOn`-derived dependency graph doesn't include `isProfileOf` targets

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
75/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python
Área
tooling

Línea de trabajo

Comience en ogc/bblocks/models.py, en BuildingBlockRegister.init, y siga cómo se ensamblan el grafo de dependencias y los metadatos dependsOn de register.json a partir de bblock.json, las referencias de schema/OpenAPI y extensionPoints. Verifique con un perfil isProfileOf-only que el grafo visible para el visor y los metadatos exportados incluyan su destino sin requerir un dependsOn duplicado.

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

Descripción

Summary

A Building Block that declares only isProfileOf (no dependsOn) renders with no visible
dependency graph in the viewer, even though it is related to another block. Blocks that are
pure profiles of a shared anchor - with no schema $ref to auto-detect, and no reason to
declare a literal dependsOn - currently have no way to show up in the graph without also
duplicating their isProfileOf target into dependsOn.

Root cause

In BuildingBlockRegister.__init__ (ogc/bblocks/models.py), the dependency graph and the
dependsOn metadata exposed in register.json are built only from:

  1. an explicit dependsOn in bblock.json,
  2. bblocks:// references auto-detected in the block's schema/OpenAPI document, and
  3. extensionPoints.baseBuildingBlock / extensionPoints.extensions.

isProfileOf is never folded in. Since isProfileOf is documented as "profiling is akin to
inheritance", it seems reasonable that a profile should also count as depending on what it
profiles for graph-visibility purposes, the same way an extension point does.

Workaround used in the meantime

In our register, we added an explicit, redundant dependsOn (pointing at the same target as
isProfileOf) to every profile block, purely so the graph renders. This works, but requires
every register author to remember to duplicate the two fields in lockstep, and semantically
overloads dependsOn for something that isn't really a runtime dependency.

Suggested fix

When building the dependency graph / exported dependsOn metadata, also include each block's
isProfileOf target(s) - either by merging them into the same dependsOn list, or by exposing
them as their own edge set that consumers (like the viewer) can render alongside dependsOn.
This would let a profile block be graph-visible from isProfileOf alone, without authors having
to declare a duplicate dependsOn.

Reference: working example of the workaround in
ogcincubator/bblocks-prov-jsonld-alt#5, where five isProfileOf-only profile blocks needed a
duplicate dependsOn added purely to appear in the viewer's graph. A related viewer-side fix for
rendering these relationships as dependents is in ogcincubator/bblocks-viewer#14.

Lenguaje dominante
Python
Estrellas
1
Forks
6
Merge medio
23 h 43 min
PR fusionados (30 d)
7

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

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 opengeospatial/bblocks-postprocess

Todos los issues de opengeospatial/bblocks-postprocess

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.