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

import across separately loaded sources does not resolve

Cerrado
  • ¿Algo no está bien?
#645 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
35/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
go
Área
api, backend

Línea de trabajo

Start with the load_from_content and conn.load entry points using the base.sysml and chapter.sysml examples, and inspect how the project/commit model handles separately loaded resources. Compare this behavior with the sysml-toolkit command that resolves the pair. Done means documenting the intended loading pattern and confirming whether cross-file imports resolve without concatenation.

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

Descripción

Summary

A model split across two files, where one imports a package from the other, fails to resolve when the two are loaded as separate sources — even from the same directory — though the same pair resolves fine when concatenated into one source, and sysml-toolkit resolves the pair without concatenation.

Version: OpenSysML v0.9.0. sysml-toolkit v0.9.1 resolves the same pair (sysmlv2 check base.sysml chapter.sysml).

Observed

base.sysml:

package Base { part def Heater; part def Timer; }

chapter.sysml:

package Chapter {
  private import Base::*;
  part def Toaster { part heater : Heater; part timer : Timer; }
}

Loading chapter.sysml alone — via load_from_content with only its own text, or via conn.load(path) with base.sysml present in the same directory — fails with unresolved reference. Concatenating both files' text into a single source and loading that works.

Question, not (yet) a bug report

We haven't established what the SysML/KerML package-import semantics, or the API's project/commit model, require for resolving imports across multiple separately-loaded resources — this may be entirely by design (e.g. a caller is expected to supply a single already-merged/pre-linked source, or to explicitly register each resource with the connection first). Rather than assert a bug, we'd like to ask: what is the intended way to load a model that spans multiple files or commits, so that imports between them resolve? If there is a documented pattern for this we've missed, a pointer would be very welcome.

Workaround in place

We concatenate sources ourselves before loading, which works but loses whatever the API's project/commit model would otherwise give us (e.g. provenance of which file/commit an element came from).

Lenguaje dominante
Go
Estrellas
39
Forks
12
Merge medio
14 h 26 min
PR fusionados (30 d)
764

Preparar el entorno

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 Open-MBEE/OpenSysML

Todos los issues de Open-MBEE/OpenSysML

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.