Template questions¶
During project creation or when an update introduces a new variable, you will be prompted with some of the following questions:
project_name¶
The name of the project, particularly for PyPI.
The final name depends on no_saltext_namespace.
Example: vault
Important
Do not include the saltext. namespace here.
integration_name¶
The name of the integrated service, used in autogenerated documentation and README.
Example: HashiCorp Vault
summary¶
A short description of the project for PyPI metadata, documentation, and README.
Example: Salt extension for interacting with HashiCorp Vault
url¶
The project’s main URL for PyPI metadata, typically the hosted git repository.
Example: https://github.com/salt-extensions/saltext-vault
source_url¶
The URL of the hosted git repository for PyPI metadata.
Example: https://github.com/salt-extensions/saltext-vault
tracker_url¶
The URL of the issue tracker for PyPI metadata.
Example: https://github.com/salt-extensions/saltext-vault/issues
package_name¶
The Python package name used for importing. The final name depends on no_saltext_namespace.
Example: vault
Important
Do not include the saltext. namespace here.
license¶
Select a license. Any license other than Apache 2.0 requires manual management.
license_classifier¶
The license classifier for PyPI metadata.
Example: License :: OSI Approved :: GNU General Public License v2 or later (GPLv2+)
Note
Only asked if a non-Apache license is selected.
loaders¶
Choose the Salt module types this extension should provide.
salt_version¶
The minimum Salt version to support. Influences package dependencies and versions that are tested against.
python_requires¶
The minimum Python version to support. Also affects pre-commit autoformatting hooks.
max_salt_version¶
The maximum Salt version to support.
Hint
This is only relevant when non-centralized workflows are used, as it affects the Salt versions tests are run against.
no_saltext_namespace¶
Whether to use the saltext. namespace for the Python package.
ssh_fixtures¶
Include test fixtures for Salt-SSH tests (salt_ssh_cli etc.). Defaults to true if wrapper modules are included.
test_containers¶
Add support for running containers in the test suite (for functional and integration tests).
workflows¶
Select a GitHub Actions workflow style:
- org
Rely on reusable workflows from the
salt-extensionsGitHub organization.- enhanced
Equivalent workflows to
org, but stored in the extension repository. You need to setup required secrets yourself.- basic
Provided for compatibility with the deprecated create-salt-extension tool (not recommended for new projects).
Note
Not asked if source_url is not on GitHub.
deploy_docs¶
Decide when to publish documentation to GitHub pages:
- never
Don’t publish documentation.
- release
Publish when a release is tagged. This ensures documentation is in sync with the released functionality.
- rolling
Publish on
pushandtagevents to the default branch. This ensures upcoming unreleased changes are displayed in the changelog.
Important
Ensure your GitHub Actions workflow is allowed to publish to your GitHub Pages site.
Note
The current workflows do not support versioned documentation.
Note
Not asked if source_url is not on GitHub or the basic workflows have been selected.
docs_url¶
The URL for hosted documentation, typically your GitHub Pages URL if using deploy_docs.
Example: https://salt-extensions.github.io/saltext-vault/
coc_contact¶
A contact email for Code of Conduct complaints.
Example: foo@b.ar
copyright_begin¶
The starting year of the copyright range.
Example: 2024
relax_pylint¶
Suppress some Pylint messages that can cause noise (consider-using-f-string)
or be time-intense (too-many-*) or difficult
(redefined-builtin, redefined-outer-name) to solve with legacy code.
Additionally suppresses unused-argument in the test suite, often caused
by requesting fixtures in the function signature instead of using
@pytest.mark.usefixtures. Note that the decorator does not work on
fixtures requesting other fixtures.