2023-12-19 Extensions Project

Meetings
,
1

Extensions Project

Attendees:

  • Campbell Barton
  • Dalai Felinto

In 2024 the Extensions project will continue, with Dalai joining the team. This meeting is part of the process of confirming the technical details of the project, as well as defining some use-cases that haven’t been accounted for. This will be re-iterated with Francesco Siddi in a meeting in January.

  • Status of the project:
    • Python 3.11 (required for the project) will land in Blender 4.1-alpha early next year.
    • Server was updated to support .txz and the manifest file.
    • Client tests are up to date.
  • Manifest schema:
    • How to specify multiple licenses (two separate “license:SPDX” lines?).
    • Can support single strings, as well as lists:
    • Proposal, to embed SPDX licenses, copyright and authors as is done for Blender’s code. e.g.
author = [
    "Developer name <[email protected]>",
    # Also support paths starting with "./"
    "./AUTHORS",
]
license = [
    # Conform to https://spdx.org/licenses/ use SPDX: prefix.
    "SPDX:ID",
]
copyright = [
    "2006-2012 Developer Name",
    "2006-2012 Company Name",
]
  • Schema open topic: which fields are hard requirements.
    • Note some licenses require a copyright, while for others it is indeed optional.
    • Find balance between not requiring developers to do too much up-front investigation into SPDX ID’s … but also set reasonable requirements for official blender.org extensions.
    • Suggestion: License (thus copyright) to be a “soft” requirements. Maybe author as well.
    • Packages without them will warn when building, and may be rejected from Blender’s official repositories, but are not required for users local repositories.
  • Unit Tests:
    • Model operators aren’t covered by tests for example.
  • Project use case and installing of add-ons:
    • Setting an addons folder comes with the same hurdle of setting an extension repository:
      both solutions (as it is) still require add-ons to be enabled.
    • Do people expect to have add-ons automatically installed?
    • If you switch between project files, are you to see a different set of add-ons? Do they auto (un)register?
    • This needs to be discussed further with the Blender Project team.
    • Potential conflicts, the same addon is enabled in the users preferences… but a different version.
  • User Extension Repository
    • No package management.
    • Managed by the users directly.
    • (unpacked) extensions in this repository are considered “Installed”
      and can be enabled/disabled as is currently done for add-ons.
    • Extensions there still require a manifest (toml).
    • Extensions still need to be “Enabled”
    • Installing new extensions (can) still go via Blender (for individual downloaded packages).
    • Extension developers can symlink directly to their version controlled repositories.
    • Key differences with current add-ons:
      • Namespaced.
      • Require own manifest (toml) for meta-data (replaces add-ons bl_info).
  • Bigger/controversial topic: Support (encourage even) hand-created packages
    • Presented proposal (still an open topic)
      • Use .zip instead of .txz
      • Remove the need for package .json file
      • Simplify names: manifest.toml
    • Short-term gain vs Long-term pain
      • e.g., flight checks during package building.
        • Check for semantic versioning.
        • Manifest schema.
    • Down-sides
      • Changes to packaging would require users who hand generate packages to update their workflow (we would be breaking their workflow).
      • Maybe the discussion is not hand-created vs blender-created, but more simple-package vs obscure-package
        • We could still encourage to go through Blender to create packages, while having them simple (.zip, no json, …).
      • Having to limit ourselves to meta-data users are easily able to maintain by hand could limit packages form containing useful information which could be generated at build time such as expected file structure & sizes which could be used for validation.
  • Next steps:
    • Server:
      • Support the new schema.
      • Update Blender Kitsu add-on to support relative import. (done by Nick)
      • Update server dummy data to comply to the new schema.
    • Client:
      • Schema update.
    • Design discussions will start next year.
15 Likes