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. Influences 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).
os_support
¶
Select supported operating systems. Usually, you should leave the default of Linux
, macOS
and Windows
, but some extensions only make sense on specific systems.
This question influences on which systems the tests are run.
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
push
andtag
events 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.
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.