xactflow-component 0.1.0__tar.gz

xactflow_component-0.1.0/LICENSE

@@ -0,0 +1,164 @@
+                   GNU LESSER GENERAL PUBLIC LICENSE
+                       Version 3, 29 June 2007
+
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+  This version of the GNU Lesser General Public License incorporates
+the terms and conditions of version 3 of the GNU General Public
+License, supplemented by the additional permissions listed below.
+
+  0. Additional Definitions.
+
+  As used herein, "this License" refers to version 3 of the GNU Lesser
+General Public License, and the "GNU GPL" refers to version 3 of the GNU
+General Public License.
+
+  "The Library" refers to a covered work governed by this License,
+other than an Application or a Combined Work as defined below.
+
+  An "Application" is any work that makes use of an interface provided
+by the Library, but which is not otherwise based on the Library.
+Defining a subclass of a class defined by the Library is deemed a mode
+of using an interface provided by the Library.
+
+  A "Combined Work" is a work produced by combining or linking an
+Application with the Library.  The particular version of the Library
+with which the Combined Work was made is also called the "Linked
+Version".
+
+  The "Minimal Corresponding Source" for a Combined Work means the
+Corresponding Source for the Combined Work, excluding any source code
+for portions of the Combined Work that, considered in isolation, are
+based on the Application, and not on the Linked Version.
+
+  The "Corresponding Application Code" for a Combined Work means the
+object code and/or source code for the Application, including any data
+and utility programs needed for reproducing the Combined Work from the
+Application, but excluding the System Libraries of the Combined Work.
+
+  1. Exception to Section 3 of the GNU GPL.
+
+  You may convey a covered work under sections 3 and 4 of this License
+without being bound by section 3 of the GNU GPL.
+
+  2. Conveying Modified Versions.
+
+  If you modify a copy of the Library, and, in your modifications, a
+facility refers to a function or data to be supplied by an Application
+that uses the facility (other than as an argument passed when the
+facility is invoked), then you may convey a copy of the modified
+version:
+
+   a) under this License, provided that you make a good faith effort to
+   ensure that, in the event an Application does not supply the
+   function or data, the facility still operates, and performs
+   whatever part of its purpose remains meaningful, or
+
+   b) under the GNU GPL, with none of the additional permissions of
+   this License applicable to that copy.
+
+  3. Object Code Incorporating Material from Library Header Files.
+
+  The object code form of an Application may incorporate material from
+a header file that is part of the Library.  You may convey such object
+code under terms of your choice, provided that, if the incorporated
+material is not limited to numerical parameters, data structure
+layouts and accessors, or small macros, inline functions and templates
+(ten or fewer lines in length), you do both of the following:
+
+   a) Give prominent notice with each copy of the object code that the
+   Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the object code with a copy of the GNU GPL and this license
+   document.
+
+  4. Combined Works.
+
+  You may convey a Combined Work under terms of your choice that,
+taken together, effectively do not restrict modification of the
+portions of the Library contained in the Combined Work and reverse
+engineering for debugging such modifications, if you also do each of
+the following:
+
+   a) Give prominent notice with each copy of the Combined Work that
+   the Library is used in it and that the Library and its use are
+   covered by this License.
+
+   b) Accompany the Combined Work with a copy of the GNU GPL and this license
+   document.
+
+   c) For a Combined Work that displays copyright notices during
+   execution, include the copyright notice for the Library among
+   these notices, as well as a reference directing the user to the
+   copies of the GNU GPL and this license document.
+
+   d) Do one of the following:
+
+       0) Convey the Minimal Corresponding Source under the terms of this
+       License, and the Corresponding Application Code in a form
+       suitable for, and under terms that permit, the user to
+       recombine or relink the Application with a modified version of
+       the Linked Version to produce a modified Combined Work, in the
+       manner specified by section 6 of the GNU GPL for conveying
+       Corresponding Source.
+
+       1) Use a suitable shared library mechanism for linking with the
+       Library.  A suitable mechanism is one that (a) uses at run time
+       a copy of the Library already present on the user's computer
+       system, and (b) will operate properly with a modified version
+       of the Library that is interface-compatible with the Linked
+       Version.
+
+   e) Provide Installation Information, but only if you would otherwise
+   be required to provide such information under section 6 of the
+   GNU GPL, and only to the extent that such information is
+   necessary to install and execute a modified version of the
+   Combined Work produced by recombining or relinking the
+   Application with a modified version of the Linked Version. (If
+   you use option 4d0, the Installation Information must accompany
+   the Minimal Corresponding Source and Corresponding Application
+   Code. If you use option 4d1, you must provide the Installation
+   Information in the manner specified by section 6 of the GNU GPL
+   for conveying Corresponding Source.)
+
+  5. Combined Libraries.
+
+  You may place library facilities that are a work based on the
+Library side by side in a single library together with other library
+facilities that are not Applications and are not covered by this
+License, and convey such a combined library under terms of your
+choice, if you do both of the following:
+
+   a) Accompany the combined library with a copy of the same work based
+   on the Library, uncombined with any other library facilities,
+   conveyed under the terms of this License.
+
+   b) Give prominent notice with the combined library that part of it
+   is a work based on the Library, and explaining where to find the
+   accompanying uncombined form of the same work.
+
+  6. Revised Versions of the GNU Lesser General Public License.
+
+  The Free Software Foundation may publish revised and/or new versions
+of the GNU Lesser General Public License from time to time. Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.
+
+  Each version is given a distinguishing version number. If the
+Library as you received it specifies that a certain numbered version
+of the GNU Lesser General Public License "or any later version"
+applies to it, you have the option of following the terms and
+conditions either of that published version or of any later version
+published by the Free Software Foundation. If the Library as you
+received it does not specify a version number of the GNU Lesser
+General Public License, you may choose any version of the GNU Lesser
+General Public License ever published by the Free Software Foundation.
+
+  If the Library as you received it specifies that a proxy can decide
+whether future versions of the GNU Lesser General Public License shall
+apply, that proxy's public statement of acceptance of any version is
+permanent authorization for you to choose that version for the
+Library.

xactflow_component-0.1.0/PKG-INFO

@@ -0,0 +1,167 @@
+Metadata-Version: 2.4
+Name: xactflow-component
+Version: 0.1.0
+Summary: XactFlow exporter plugin that serializes an ipxact.Component into IEEE 1685-2022 IP-XACT XML.
+Author: Maxime Travaillard
+License-Expression: LGPL-3.0-only
+Project-URL: Repository, https://github.com/IP-XACT/XactFlow-component
+Project-URL: Issues, https://github.com/IP-XACT/XactFlow-component/issues
+Keywords: IP-XACT,IEEE 1685,XML,Compiler,XactFlow,Component
+Classifier: Development Status :: 3 - Alpha
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3 :: Only
+Classifier: Programming Language :: Python :: 3.9
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Programming Language :: Python :: 3.12
+Classifier: Programming Language :: Python :: 3.13
+Classifier: Programming Language :: Python :: 3.14
+Classifier: Topic :: Scientific/Engineering
+Requires-Python: >=3.9
+Description-Content-Type: text/markdown
+License-File: LICENSE
+Requires-Dist: xactflow
+Requires-Dist: ipxact-compiler
+Requires-Dist: lxml
+Provides-Extra: dev
+Requires-Dist: pytest; extra == "dev"
+Dynamic: license-file
+
+# xactflow-component
+
+A [XactFlow](https://github.com/IP-XACT/XactFlow) exporter plugin that serializes an
+`ipxact.Component` object into a valid [IEEE 1685-2022](https://standards.ieee.org/ieee/1685/10307/)
+IP-XACT `component` XML document.
+
+[`ipxact-compiler`](https://github.com/IP-XACT/ipxact-compiler) reads IP-XACT XML and hands back
+Python objects, it never writes XML. This package is the other direction: given a `Component`,
+it writes the XML back out.
+
+## Installation
+
+```bash
+pip install xactflow-component
+```
+
+For local development, `requirements-dev.txt` overrides `ipxact-compiler` and `xactflow` to
+local installations. It can be modified to adapt the paths or to keep either version on PyPI.
+
+```bash
+pip install -r requirements-dev.txt -e .
+```
+
+Requires Python >= 3.9.
+
+## Usage
+
+```python
+from pathlib import Path
+
+import ipxact
+from xactflow_component import ComponentExporter
+
+component = ipxact.parse_file("apb_uart.xml")   # or get one from an importer
+ComponentExporter().export(component, Path("out"))
+# writes out/apb_uart.xml
+```
+
+The output file is named after the component's VLNV name (`<vlnv.name>.xml`) inside `output_dir`,
+which is created if it does not exist.
+
+Lower-level entry points are available for callers that want the tree or the bytes rather than a
+file:
+
+```python
+from xactflow_component import component_to_bytes, write_component, write_component_file
+
+element = write_component(component)              # the lxml ipxact:component root element
+data = component_to_bytes(component)              # pretty-printed bytes, with an XML declaration
+path = write_component_file(component, "out.xml") # writes and returns the path
+```
+
+Once installed, the exporter registers itself under the `xactflow.exporters` entry point group as
+`component`, so `xactflow component ...` becomes available as a XactFlow CLI subcommand. Note that
+XactFlow's CLI always elaborates a design before calling an exporter, so for now the way to use
+this package is to call `ComponentExporter().export(...)` directly on a `Component`.
+
+`export()` raises `TypeError` for anything that is not an `ipxact.Component`. Accepting an
+`ElaboratedDesign` (flattening a resolved multi-instance design into one boundary component) is a
+planned later addition, not an oversight.
+
+## Design notes
+
+- **Element order comes from the XSD, not from the dataclasses.** `componentType`'s sequence puts
+  `displayName`/`shortDescription`/`description` right after the VLNV and `typeDefinitions`/
+  `powerDomains` before `busInterfaces`, while the `Component` dataclass declares those fields
+  last. The same mismatch repeats in almost every nested type, because IP-XACT's `nameGroup` opens
+  an element while the corresponding Python fields are trailing optionals. Every writer here
+  follows the schema.
+- **Expressions are written verbatim.** Anything typed `Expression` in `ipxact-compiler`
+  (`addressOffset`, `size`, `range`, `width`, `bitOffset`, `bitWidth`, ...) is a raw string and is
+  emitted unchanged, never evaluated or reformatted.
+- **Vendor extensions stay identical.** Their content is not IP-XACT's to define, so each
+  fragment is re-inserted as parsed.
+- **No `xsi:schemaLocation`.** The root element declares only the IP-XACT namespace, matching the
+  fixtures in `ipxact-compiler`. A document is identified by its namespace and root element, and a
+  hard-coded schema location would point at a path that does not exist on the reader's machine.
+- **Defaults are omitted.** Attributes and elements whose value equals the schema default
+  (`resolve="immediate"`, `type="string"`, `misalignmentAllowed="true"`, `connectionRequired`
+  false, and so on) are left out, which keeps the output close to hand-written IP-XACT and still
+  round-trips exactly.
+- **Required XSD choices raise `ValueError` when no arm is set, instead of emitting invalid
+  XML.** Several dataclasses share one field across XSD contexts with different required-ness,
+  or expose independent sibling fields that the schema only allows together. Rather than silently
+  writing an incomplete element for these, the writer raises a specific error naming the missing
+  field.
+
+## Known gaps
+
+These come from constructs the IEEE 1685-2022 schema requires but `ipxact-compiler`'s object model
+deliberately does not carry. Such a component still round-trips through this writer and back
+through the parser unchanged, but the XML it produces will not satisfy the XSD:
+
+- **Banks have no `baseAddress`.** `ipxact.Bank` does not model one, while the schema's
+  `addressBankType` (a bank directly inside a `memoryMap`, `memoryRemap` or `localMemoryMap`)
+  requires it. Banks nested inside another bank are unaffected.
+- **Structured ports have no `structPortTypeDefs`.** `ipxact.StructuredPort` leaves out the
+  language-specific type bindings that `portStructuredType` requires.
+- **`externalTypeDefinitions` has an optional name.** The schema's `nameGroup` requires one.
+- **`File.dependencies` is write-only.** `ipxact-compiler`'s `parse_file` does not read `dependency`
+  children of a `file` back, so setting them means the value is written but does not survive a
+  re-parse. (`FileSet.dependencies` round-trips normally.)
+- **`MemoryArray.stride` on a register or register file is write-only.** This writer emits
+  `ipxact:stride` correctly, but `ipxact-compiler` reads it with a truth test on the element, which
+  is false for a childless element, so the value comes back as `None`. `bitStride` on a field is
+  unaffected.
+
+The writer also does not invent content the object model leaves out, so a `Component` that is
+under-specified relative to the schema produces XML that says so: a `register` with no fields, a
+`memoryRemap` with no `modeRef`, a `channel` with fewer than two `busInterfaceRef`s, a `file` with
+no `fileType`, or a `componentGenerator` with more than one `transportMethod` will each fail
+validation rather than being silently patched up. Validating the output against `component.xsd` is
+the way to catch that.
+
+Other deliberate simplifications, all inherited from `ipxact-compiler`'s object model, so there is
+nothing to write: `accessHandles`, `executableImage`, `powerConstraints`, `wireTypeDefs`/
+`domainTypeDefs`/`signalTypeDefs`/`transTypeDefs`, `portPackets`, a port's `arrays`/`access`, a
+`portMap`'s logical `range` and physical `partSelect`/`subPort`, `clearboxElementRefs`,
+`fileSet/function`, a `file`'s `define`/`imageType`/`targetName`, `viewLinks`/`modeLinks`/
+`resetTypeLinks`, a field's `aliasOf` alternative, and the `*DefinitionRef` type-definition
+indirection on memory map elements.
+
+## Development
+
+```bash
+pip install -r requirements-dev.txt -e .
+pytest
+```
+
+The tests round-trip both `ipxact-compiler`'s `apb_uart.xml` fixture and hand-built components
+through the writer and back through the parser, validate the written XML against `component.xsd`
+with `lxml.etree.XMLSchema.assertValid`, and re-run `xactflow.SCR.run_single_doc_checks` on the
+result. They expect `ipxact-compiler` and the IEEE 1685-2022 schema (`IEEE_1685-2022/schema/
+1685-2022/`) as sibling checkouts; set `IPXACT_SCHEMA_DIR` to point the schema somewhere else.
+
+## License
+
+LGPL-3.0. See [LICENSE](LICENSE).

xactflow_component-0.1.0/README.md

@@ -0,0 +1,138 @@
+# xactflow-component
+
+A [XactFlow](https://github.com/IP-XACT/XactFlow) exporter plugin that serializes an
+`ipxact.Component` object into a valid [IEEE 1685-2022](https://standards.ieee.org/ieee/1685/10307/)
+IP-XACT `component` XML document.
+
+[`ipxact-compiler`](https://github.com/IP-XACT/ipxact-compiler) reads IP-XACT XML and hands back
+Python objects, it never writes XML. This package is the other direction: given a `Component`,
+it writes the XML back out.
+
+## Installation
+
+```bash
+pip install xactflow-component
+```
+
+For local development, `requirements-dev.txt` overrides `ipxact-compiler` and `xactflow` to
+local installations. It can be modified to adapt the paths or to keep either version on PyPI.
+
+```bash
+pip install -r requirements-dev.txt -e .
+```
+
+Requires Python >= 3.9.
+
+## Usage
+
+```python
+from pathlib import Path
+
+import ipxact
+from xactflow_component import ComponentExporter
+
+component = ipxact.parse_file("apb_uart.xml")   # or get one from an importer
+ComponentExporter().export(component, Path("out"))
+# writes out/apb_uart.xml
+```
+
+The output file is named after the component's VLNV name (`<vlnv.name>.xml`) inside `output_dir`,
+which is created if it does not exist.
+
+Lower-level entry points are available for callers that want the tree or the bytes rather than a
+file:
+
+```python
+from xactflow_component import component_to_bytes, write_component, write_component_file
+
+element = write_component(component)              # the lxml ipxact:component root element
+data = component_to_bytes(component)              # pretty-printed bytes, with an XML declaration
+path = write_component_file(component, "out.xml") # writes and returns the path
+```
+
+Once installed, the exporter registers itself under the `xactflow.exporters` entry point group as
+`component`, so `xactflow component ...` becomes available as a XactFlow CLI subcommand. Note that
+XactFlow's CLI always elaborates a design before calling an exporter, so for now the way to use
+this package is to call `ComponentExporter().export(...)` directly on a `Component`.
+
+`export()` raises `TypeError` for anything that is not an `ipxact.Component`. Accepting an
+`ElaboratedDesign` (flattening a resolved multi-instance design into one boundary component) is a
+planned later addition, not an oversight.
+
+## Design notes
+
+- **Element order comes from the XSD, not from the dataclasses.** `componentType`'s sequence puts
+  `displayName`/`shortDescription`/`description` right after the VLNV and `typeDefinitions`/
+  `powerDomains` before `busInterfaces`, while the `Component` dataclass declares those fields
+  last. The same mismatch repeats in almost every nested type, because IP-XACT's `nameGroup` opens
+  an element while the corresponding Python fields are trailing optionals. Every writer here
+  follows the schema.
+- **Expressions are written verbatim.** Anything typed `Expression` in `ipxact-compiler`
+  (`addressOffset`, `size`, `range`, `width`, `bitOffset`, `bitWidth`, ...) is a raw string and is
+  emitted unchanged, never evaluated or reformatted.
+- **Vendor extensions stay identical.** Their content is not IP-XACT's to define, so each
+  fragment is re-inserted as parsed.
+- **No `xsi:schemaLocation`.** The root element declares only the IP-XACT namespace, matching the
+  fixtures in `ipxact-compiler`. A document is identified by its namespace and root element, and a
+  hard-coded schema location would point at a path that does not exist on the reader's machine.
+- **Defaults are omitted.** Attributes and elements whose value equals the schema default
+  (`resolve="immediate"`, `type="string"`, `misalignmentAllowed="true"`, `connectionRequired`
+  false, and so on) are left out, which keeps the output close to hand-written IP-XACT and still
+  round-trips exactly.
+- **Required XSD choices raise `ValueError` when no arm is set, instead of emitting invalid
+  XML.** Several dataclasses share one field across XSD contexts with different required-ness,
+  or expose independent sibling fields that the schema only allows together. Rather than silently
+  writing an incomplete element for these, the writer raises a specific error naming the missing
+  field.
+
+## Known gaps
+
+These come from constructs the IEEE 1685-2022 schema requires but `ipxact-compiler`'s object model
+deliberately does not carry. Such a component still round-trips through this writer and back
+through the parser unchanged, but the XML it produces will not satisfy the XSD:
+
+- **Banks have no `baseAddress`.** `ipxact.Bank` does not model one, while the schema's
+  `addressBankType` (a bank directly inside a `memoryMap`, `memoryRemap` or `localMemoryMap`)
+  requires it. Banks nested inside another bank are unaffected.
+- **Structured ports have no `structPortTypeDefs`.** `ipxact.StructuredPort` leaves out the
+  language-specific type bindings that `portStructuredType` requires.
+- **`externalTypeDefinitions` has an optional name.** The schema's `nameGroup` requires one.
+- **`File.dependencies` is write-only.** `ipxact-compiler`'s `parse_file` does not read `dependency`
+  children of a `file` back, so setting them means the value is written but does not survive a
+  re-parse. (`FileSet.dependencies` round-trips normally.)
+- **`MemoryArray.stride` on a register or register file is write-only.** This writer emits
+  `ipxact:stride` correctly, but `ipxact-compiler` reads it with a truth test on the element, which
+  is false for a childless element, so the value comes back as `None`. `bitStride` on a field is
+  unaffected.
+
+The writer also does not invent content the object model leaves out, so a `Component` that is
+under-specified relative to the schema produces XML that says so: a `register` with no fields, a
+`memoryRemap` with no `modeRef`, a `channel` with fewer than two `busInterfaceRef`s, a `file` with
+no `fileType`, or a `componentGenerator` with more than one `transportMethod` will each fail
+validation rather than being silently patched up. Validating the output against `component.xsd` is
+the way to catch that.
+
+Other deliberate simplifications, all inherited from `ipxact-compiler`'s object model, so there is
+nothing to write: `accessHandles`, `executableImage`, `powerConstraints`, `wireTypeDefs`/
+`domainTypeDefs`/`signalTypeDefs`/`transTypeDefs`, `portPackets`, a port's `arrays`/`access`, a
+`portMap`'s logical `range` and physical `partSelect`/`subPort`, `clearboxElementRefs`,
+`fileSet/function`, a `file`'s `define`/`imageType`/`targetName`, `viewLinks`/`modeLinks`/
+`resetTypeLinks`, a field's `aliasOf` alternative, and the `*DefinitionRef` type-definition
+indirection on memory map elements.
+
+## Development
+
+```bash
+pip install -r requirements-dev.txt -e .
+pytest
+```
+
+The tests round-trip both `ipxact-compiler`'s `apb_uart.xml` fixture and hand-built components
+through the writer and back through the parser, validate the written XML against `component.xsd`
+with `lxml.etree.XMLSchema.assertValid`, and re-run `xactflow.SCR.run_single_doc_checks` on the
+result. They expect `ipxact-compiler` and the IEEE 1685-2022 schema (`IEEE_1685-2022/schema/
+1685-2022/`) as sibling checkouts; set `IPXACT_SCHEMA_DIR` to point the schema somewhere else.
+
+## License
+
+LGPL-3.0. See [LICENSE](LICENSE).

xactflow_component-0.1.0/pyproject.toml

@@ -0,0 +1,57 @@
+[build-system]
+requires = ["setuptools>=77"]
+build-backend = "setuptools.build_meta"
+
+[project]
+name = "xactflow-component"
+dynamic = ["version"]
+description = "XactFlow exporter plugin that serializes an ipxact.Component into IEEE 1685-2022 IP-XACT XML."
+readme = "README.md"
+license = "LGPL-3.0-only"
+license-files = ["LICENSE"]
+authors = [
+    { name = "Maxime Travaillard"},
+]
+requires-python = ">=3.9"
+dependencies = [
+    "xactflow",
+    "ipxact-compiler",
+    "lxml",
+]
+keywords = [
+    "IP-XACT", "IEEE 1685", "XML", "Compiler",
+    "XactFlow", "Component",
+]
+classifiers = [
+    "Development Status :: 3 - Alpha",
+    "Programming Language :: Python :: 3",
+    "Programming Language :: Python :: 3 :: Only",
+    "Programming Language :: Python :: 3.9",
+    "Programming Language :: Python :: 3.10",
+    "Programming Language :: Python :: 3.11",
+    "Programming Language :: Python :: 3.12",
+    "Programming Language :: Python :: 3.13",
+    "Programming Language :: Python :: 3.14",
+    "Topic :: Scientific/Engineering",
+]
+
+[project.urls]
+Repository = "https://github.com/IP-XACT/XactFlow-component"
+Issues = "https://github.com/IP-XACT/XactFlow-component/issues"
+
+[project.optional-dependencies]
+dev = [
+    "pytest",
+]
+
+[project.entry-points."xactflow.exporters"]
+component = "xactflow_component:ComponentExporter"
+
+[tool.setuptools.dynamic]
+version = {attr = "xactflow_component.__version__"}
+
+[tool.setuptools.packages.find]
+where = ["src"]
+
+[tool.setuptools.package-data]
+xactflow_component = ["py.typed"]

xactflow_component-0.1.0/setup.cfg

@@ -0,0 +1,4 @@
+[egg_info]
+tag_build = 
+tag_date = 0
+

xactflow_component-0.1.0/src/xactflow_component/__init__.py

@@ -0,0 +1,38 @@
+from __future__ import annotations
+
+__version__ = "0.1.0"
+
+from pathlib import Path
+
+import ipxact
+from xactflow import Exporter
+
+from .component_writer import component_to_bytes, write_component, write_component_file
+
+__all__ = [
+    "ComponentExporter",
+    "__version__",
+    "component_to_bytes",
+    "write_component",
+    "write_component_file",
+]
+
+
+class ComponentExporter(Exporter):
+    """Serialize an ipxact.Component into an IEEE 1685-2022 IP-XACT component XML file.
+
+    The output file is named after the component's VLNV name into output_dir.
+    """
+
+    name = "component"
+
+    def export(self, subject: object, output_dir: Path, **options: object) -> None:
+        if not isinstance(subject, ipxact.Component):
+            # ElaboratedDesign support (flattening a resolved multi-instance design into one
+            # boundary Component) is an agreed-on later addition.
+            raise TypeError(
+                f"xactflow-component only supports ipxact.Component, got {type(subject).__name__}"
+            )
+        output_dir = Path(output_dir)
+        output_dir.mkdir(parents=True, exist_ok=True)
+        write_component_file(subject, output_dir / f"{subject.vlnv.name}.xml")