Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • nomad-FAIR nomad-FAIR
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 216
    • Issues 216
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 27
    • Merge requests 27
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • nomad-labnomad-lab
  • nomad-FAIRnomad-FAIR
  • Issues
  • #549
Closed
Open
Issue created May 26, 2021 by Markus Scheidgen@mscheidgOwner0 of 5 checklist items completed0/5 checklist items

Metainfo versioning

As an requirement for effective #419 (closed) and for general future proofing, we should version the metainfo.

Ideally:

  • different versions of the metainfo can be used within the same Python runtime
  • NOMAD can use archives based on different metainfo versions
  • the UI (metainfo and archive browser) are aware of different metainfo version

Problems to solve:

  • metainfo packages have to state their version
  • specific metainfo versions can be imported, e.g. through specific import mechanism
  • metainfo packages of all available versions are packaged into nomad-lab Python package
  • m_to_dict, m_from_dict and nomad.archive package write and read versions
  • search and archive API respect versions

How can this ever work:

  • Each Python module is its own namespace and imported names in different modules can come from different sources (e.g. versions).
  • Python has a very flexible module and import system with lots of hooks
  • Unfortunately, one can only hook into the first search for a python module/package name
  • We internally add versions to the module name of metainfo packages
  • Python modules can be "virtual", e.g. do not have to exist as files. We can implement finders/loaders/importers that resolve (versioned) metainfo package names
Assignee
Assign to
Time tracking