Identifying Schema
Specify and locate schema for which bindings should be generated.
--schema-location
Add the location of an entrypoint schema. The provided value should be
a URL; if it does not have a URL scheme (e.g., http:), it is assumed
to be a file, and if it is not an absolute path is located relative to
the schemaRoot.
--schema-root
The directory from which entrypoint schemas specified as relative file
paths will be read.
--schema-stripped-prefix
Optional string that is stripped from the beginning of schemaLocation
values before loading from them. This applies only to the values of
schemaLocation attributes in import and include elements. Its
purpose is to convert absolute schema locations into relative ones to
allow offline processing when all schema are available in a local
directory. See schemaRoot.
--location-prefix-rewrite
Add a rewrite entry for schema locations. Parameter values are strings
of the form pfx=sub. The effect is that a schema location that
begins with pfx is rewritten so that it instead begins with sub.
--uri-content-archive-directory
The directory path into which any content retrieved by URI will be
written. This serves as a local cache, and to give you an opportunity to
inspect material retrieved from some other system. @rtype: str
Configuring Bindings
Specify where generated bindings should be written, and how they will be accessed from Python.
--module
Add a module name corresponding to an entrypoint schema. The namespace
defined by the corresponding schema will be written to a binding using
the given module name, adjusted by L{modulePrefix}.
--module-prefix
The prefix for binding modules. The base name for the module holding a
binding is taken from the moduleList, moduleMap, or an XMLNS prefix
associated with the namespace in a containing schema. This value, if
present, is used as a prefix to allow a deeper module hierarchy.
--binding-root
The directory path into which generated bindings will be written.
@rtype: str
--write-for-customization
Indicates whether the binding Python code should be written into a sub-
module for customization. If enabled, a module path.to.namespace
will be written to the file path/to/raw/namespace.py, so that the
file path/to/namespace.py can import it and override behavior. This
option turns on the feature.
--no-write-for-customization
Indicates whether the binding Python code should be written into a sub-
module for customization. If enabled, a module path.to.namespace
will be written to the file path/to/raw/namespace.py, so that the
file path/to/namespace.py can import it and override behavior. This
option turns off the feature (default).
Reading Namespace Archives
Locating and loading (or inhibiting load of) namespace archives.
--archive-path
A colon-separated list of paths from which namespace archives can be
read. The default path is the contents of the PYXB_ARCHIVE_PATH
environment variable, or the standard path configured at installation
time. Any file with the extension .wxs found in one of these
directories is examined to see whether it is a namespace archive.
--import-augmentable-namespace
Mark that the specified namespace may be imported by new bindings.
Normally namespaces that are available from archives are considered to
be complete, and schema locations in import directives are ignored. Use
this to indicate that the bindings being generated import new bindings.
Note that attempts to import schema that contributed to the archive will
only be detected if the archive was generated from the same
schemaLocation URI; if the archive was generated from a different source
component definitions might conflict.
--no-load-namespace
Mark that the specified namespace should not be loaded from an archive.
Use this when you are generating bindings for an application that has a
restricted profile of a namespace that would otherwise be read from an
archive. Be aware that this removes any knowledge of any archive in
which this namespace is present as a non-private member.
Writing Namespace Archives
Control the location and content of a namespace archive corresponding to a binding generation.
--archive-to-file
Optional file into which the archive of namespaces will be written.
Subsequent generation actions can read pre-parsed namespaces from this
file, and therefore reference the bindings that were built earlier
rather than re-generating them. The file name should normally end with
.wxs.
--public-namespace
Indicates, for specific namespaces, whether their visibility in the
archive should be public or private. This option adds the namespace as a
public archive member.
--private-namespace
Indicates, for specific namespaces, whether their visibility in the
archive should be public or private. This option adds the namespace as a
private archive member.
--default-namespace-public
Indicates whether unmentioned namespaces will be public or private
(default) in the archive. A namespace is mentioned if it is the target
namespace of an entrypoint schema, or appears in a namespace visibility
specification. I.e., this default applies only to namespaces that are
modified as a result of including some schema, which is generally a
local customization of something. This option makes the default
public (default).
--default-namespace-private
Indicates whether unmentioned namespaces will be public or private
(default) in the archive. A namespace is mentioned if it is the target
namespace of an entrypoint schema, or appears in a namespace visibility
specification. I.e., this default applies only to namespaces that are
modified as a result of including some schema, which is generally a
local customization of something. This option makes the default
private.
Configuring Binding Code Generation
Control the style and content of the generated bindings. This is not well-supported, and you are advised to pretend these options don’t exist.
--validate-changes
Indicates whether the bindings should validate mutations against the
content model. This option turns on validation (default).
--no-validate-changes
Indicates whether the bindings should validate mutations against the
content model. This option turns off validation.
Maintainer Options
Don’t use these. They don’t exist. If they did, they’d do different things at different times, and if you used them you’d probably be sorry.
--allow-absent-module
Indicates whether the code generator is permitted to process namespace
for which no module path can be determined. Use this only when
generating bindings that will not be referenced by other bindings. This
option turns on the feature.
--no-allow-absent-module
Indicates whether the code generator is permitted to process namespace
for which no module path can be determined. Use this only when
generating bindings that will not be referenced by other bindings. This
option turns off the feature (default).
--allow-builtin-generation
Indicates whether bindings will be written for namespaces that are
built-in to PyXB. This must be enabled when building bindings for the
XML, XMLSchema instance, and other built-in namespaces. Normally
generation of these namespaces is inhibited lest it produce
inconsistencies. This option turns on the feature.
--no-allow-builtin-generation
Indicates whether bindings will be written for namespaces that are
built-in to PyXB. This must be enabled when building bindings for the
XML, XMLSchema instance, and other built-in namespaces. Normally
generation of these namespaces is inhibited lest it produce
inconsistencies. This option turns off the feature (default).