A command line tool for generating Markdown documentation and .env files from pydantic BaseSettings.
MIT License
Bot releases are hidden (Show)
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
json_schema_extra={"possible_values": [...]}
must be list[list[str]]
instead of previous list[tuple[str, ...]]
. Using tuple
results in failing type checks. Examples of valid values and their Markdown rendering:
["foo", "bar"]
:`foo`, `bar`
[["foo"], ["bar"]]
:
- `foo`
- `bar`
[["foo", "explanation of foo"], ["bar", "explanation of bar"]]
:
- `foo`: explanation of foo
- `bar`: explanation of bar
env_prefix
from pydantic_settings.SettingsConfigDict
by @dekkers in #29.env_nested_delimiter
from pydantic_settings.SettingsConfigDict
.possible_values
and examples
sections, so that examples
are displayed before possible_values
. This is the original display order from 2.x
.possible_values
.possible_values
for tuples.None
as a default value.possible_values
removed in 3.0.0
. Since arbitrary **extra
is no longer supported in pydantic>=2.0
, the possible_values
are now passed as json_schema_extra={"possible_values": [...]}
. If both the field is type of Literal
and possible_values
is specified, possible_values
will be used. It accepts:
["foo", "bar"]
. This will be formatted either as a single line or an unordered list, depending on the length of the string. Example of the resulting Markdown:`foo`, `bar`
[("foo", ), ("bar", )]
. This will be formatted as an unordered list. Example of the resulting Markdown:
- `foo`
- `bar`
[("foo", "explanation of foo"), ("bar", "explanation of bar")]
. Example of the resulting Markdown:
- `foo`: explanation of foo
- `bar`: explanation of bar
examples
by moving them in json_schema_extra["examples": ...]
. It accepts all the formats that possible_values
accepts, plus a plain string, which won't be formatted on the output. If both examples
and json_schema_extra.examples
are present, json_schema_extra.examples
will be used.validation_alias
when used.Upgrade to pydantic
2.x. If you need to use pydantic 1.x, please use the 2.x
release of settings-doc
. New features will be available only in settings-doc
3.x and later, unless a backport is requested.
The upgrade changes couple of things in the pydantic
library that also need to be reflected in the templates:
pydantic.BaseSettings
is now pydantic_settings.BaseSettings
pydantic.Field
no longer accepts arbitrary **kwargs
. This has several implications for the Jinja2 templates:
field.field_info
is no longer available. All the attributes have moved to the field
object itself. For example field.field_info.description
is now field.description
.json_schema_extra
must be passed as a keyword argument and contain a dictionary. This is then available in the Jinja2 templates as field.json_schema_extra
instead of the previous field.field_info.extra
.The type of the field exposed to templates changed from ModelField
to FieldInfo
. This means that:
FieldInfo
no longer contain the name of the settings key. Therefore, fields
has been changed to list[tuple[str, FieldInfo]]
(instead of list[ModelField]
), where the str
value is name of the settings key. To iterate over the fields, use for env_name, field in fields
instead of for field in fields
.ModelField.type_
has changed to FieldInfo.annotation
.ModelField.required
has changed to FieldInfo.is_required()
.ModelField.default is not None
has changed to FieldInfo.default is not pydantic_core.PydanticUndefined
. A new helper function has_default_value(field)
has been added to the templates to make this easier to check.FieldInfo
type is typing.Literal
has been abstracted into helper function is_typing_literal
. The check is different for Python 3.8 and for later versions of Python.classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
json_schema_extra={"possible_values": [...]}
must be list[list[str]]
instead of previous list[tuple[str, ...]]
. Using tuple
results in failing type checks. Examples of valid values and their Markdown rendering:
["foo", "bar"]
:`foo`, `bar`
[["foo"], ["bar"]]
:
- `foo`
- `bar`
[["foo", "explanation of foo"], ["bar", "explanation of bar"]]
:
- `foo`: explanation of foo
- `bar`: explanation of bar
env_prefix
from pydantic_settings.SettingsConfigDict
by @dekkers in #29.env_nested_delimiter
from pydantic_settings.SettingsConfigDict
.possible_values
and examples
sections, so that examples
are displayed before possible_values
. This is the original display order from 2.x
.possible_values
.possible_values
for tuples.None
as a default value.possible_values
removed in 3.0.0
. Since arbitrary **extra
is no longer supported in pydantic>=2.0
, the possible_values
are now passed as json_schema_extra={"possible_values": [...]}
. If both the field is type of Literal
and possible_values
is specified, possible_values
will be used. It accepts:
["foo", "bar"]
. This will be formatted either as a single line or an unordered list, depending on the length of the string. Example of the resulting Markdown:`foo`, `bar`
[("foo", ), ("bar", )]
. This will be formatted as an unordered list. Example of the resulting Markdown:
- `foo`
- `bar`
[("foo", "explanation of foo"), ("bar", "explanation of bar")]
. Example of the resulting Markdown:
- `foo`: explanation of foo
- `bar`: explanation of bar
examples
by moving them in json_schema_extra["examples": ...]
. It accepts all the formats that possible_values
accepts, plus a plain string, which won't be formatted on the output. If both examples
and json_schema_extra.examples
are present, json_schema_extra.examples
will be used.validation_alias
when used.Upgrade to pydantic
2.x. If you need to use pydantic 1.x, please use the 2.x
release of settings-doc
. New features will be available only in settings-doc
3.x and later, unless a backport is requested.
The upgrade changes couple of things in the pydantic
library that also need to be reflected in the templates:
pydantic.BaseSettings
is now pydantic_settings.BaseSettings
pydantic.Field
no longer accepts arbitrary **kwargs
. This has several implications for the Jinja2 templates:
field.field_info
is no longer available. All the attributes have moved to the field
object itself. For example field.field_info.description
is now field.description
.json_schema_extra
must be passed as a keyword argument and contain a dictionary. This is then available in the Jinja2 templates as field.json_schema_extra
instead of the previous field.field_info.extra
.The type of the field exposed to templates changed from ModelField
to FieldInfo
. This means that:
FieldInfo
no longer contain the name of the settings key. Therefore, fields
has been changed to list[tuple[str, FieldInfo]]
(instead of list[ModelField]
), where the str
value is name of the settings key. To iterate over the fields, use for env_name, field in fields
instead of for field in fields
.ModelField.type_
has changed to FieldInfo.annotation
.ModelField.required
has changed to FieldInfo.is_required()
.ModelField.default is not None
has changed to FieldInfo.default is not pydantic_core.PydanticUndefined
. A new helper function has_default_value(field)
has been added to the templates to make this easier to check.FieldInfo
type is typing.Literal
has been abstracted into helper function is_typing_literal
. The check is different for Python 3.8 and for later versions of Python.classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
possible_values
and examples
sections, so that examples
are displayed before possible_values
. This is the original display order from 2.x
.possible_values
.possible_values
for tuples.None
as a default value.possible_values
removed in 3.0.0
. Since arbitrary **extra
is no longer supported in pydantic>=2.0
, the possible_values
are now passed as json_schema_extra={"possible_values": [...]}
. If both the field is type of Literal
and possible_values
is specified, possible_values
will be used. It accepts:
["foo", "bar"]
. This will be formatted either as a single line or an unordered list, depending on the length of the string. Example of the resulting Markdown:`foo`, `bar`
[("foo", ), ("bar", )]
. This will be formatted as an unordered list. Example of the resulting Markdown:
- `foo`
- `bar`
[("foo", "explanation of foo"), ("bar", "explanation of bar")]
. Example of the resulting Markdown:
- `foo`: explanation of foo
- `bar`: explanation of bar
examples
by moving them in json_schema_extra["examples": ...]
. It accepts all the formats that possible_values
accepts, plus a plain string, which won't be formatted on the output. If both examples
and json_schema_extra.examples
are present, json_schema_extra.examples
will be used.validation_alias
when used.Upgrade to pydantic
2.x. If you need to use pydantic 1.x, please use the 2.x
release of settings-doc
. New features will be available only in settings-doc
3.x and later, unless a backport is requested.
The upgrade changes couple of things in the pydantic
library that also need to be reflected in the templates:
pydantic.BaseSettings
is now pydantic_settings.BaseSettings
pydantic.Field
no longer accepts arbitrary **kwargs
. This has several implications for the Jinja2 templates:
field.field_info
is no longer available. All the attributes have moved to the field
object itself. For example field.field_info.description
is now field.description
.json_schema_extra
must be passed as a keyword argument and contain a dictionary. This is then available in the Jinja2 templates as field.json_schema_extra
instead of the previous field.field_info.extra
.The type of the field exposed to templates changed from ModelField
to FieldInfo
. This means that:
FieldInfo
no longer contain the name of the settings key. Therefore, fields
has been changed to list[tuple[str, FieldInfo]]
(instead of list[ModelField]
), where the str
value is name of the settings key. To iterate over the fields, use for env_name, field in fields
instead of for field in fields
.ModelField.type_
has changed to FieldInfo.annotation
.ModelField.required
has changed to FieldInfo.is_required()
.ModelField.default is not None
has changed to FieldInfo.default is not pydantic_core.PydanticUndefined
. A new helper function has_default_value(field)
has been added to the templates to make this easier to check.FieldInfo
type is typing.Literal
has been abstracted into helper function is_typing_literal
. The check is different for Python 3.8 and for later versions of Python.classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
possible_values
.possible_values
for tuples.None
as a default value.possible_values
removed in 3.0.0
. Since arbitrary **extra
is no longer supported in pydantic>=2.0
, the possible_values
are now passed as json_schema_extra={"possible_values": [...]}
. If both the field is type of Literal
and possible_values
is specified, possible_values
will be used. It accepts:
["foo", "bar"]
. This will be formatted either as a single line or an unordered list, depending on the length of the string. Example of the resulting Markdown:`foo`, `bar`
[("foo", ), ("bar", )]
. This will be formatted as an unordered list. Example of the resulting Markdown:
- `foo`
- `bar`
[("foo", "explanation of foo"), ("bar", "explanation of bar")]
. Example of the resulting Markdown:
- `foo`: explanation of foo
- `bar`: explanation of bar
examples
by moving them in json_schema_extra["examples": ...]
. It accepts all the formats that possible_values
accepts, plus a plain string, which won't be formatted on the output. If both examples
and json_schema_extra.examples
are present, json_schema_extra.examples
will be used.validation_alias
when used.Upgrade to pydantic
2.x. If you need to use pydantic 1.x, please use the 2.x
release of settings-doc
. New features will be available only in settings-doc
3.x and later, unless a backport is requested.
The upgrade changes couple of things in the pydantic
library that also need to be reflected in the templates:
pydantic.BaseSettings
is now pydantic_settings.BaseSettings
pydantic.Field
no longer accepts arbitrary **kwargs
. This has several implications for the Jinja2 templates:
field.field_info
is no longer available. All the attributes have moved to the field
object itself. For example field.field_info.description
is now field.description
.json_schema_extra
must be passed as a keyword argument and contain a dictionary. This is then available in the Jinja2 templates as field.json_schema_extra
instead of the previous field.field_info.extra
.The type of the field exposed to templates changed from ModelField
to FieldInfo
. This means that:
FieldInfo
no longer contain the name of the settings key. Therefore, fields
has been changed to list[tuple[str, FieldInfo]]
(instead of list[ModelField]
), where the str
value is name of the settings key. To iterate over the fields, use for env_name, field in fields
instead of for field in fields
.ModelField.type_
has changed to FieldInfo.annotation
.ModelField.required
has changed to FieldInfo.is_required()
.ModelField.default is not None
has changed to FieldInfo.default is not pydantic_core.PydanticUndefined
. A new helper function has_default_value(field)
has been added to the templates to make this easier to check.FieldInfo
type is typing.Literal
has been abstracted into helper function is_typing_literal
. The check is different for Python 3.8 and for later versions of Python.classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
possible_values
removed in 3.0.0
. Since arbitrary **extra
is no longer supported in pydantic>=2.0
, the possible_values
are now passed as json_schema_extra={"possible_values": [...]}
. If both the field is type of Literal
and possible_values
is specified, possible_values
will be used. It accepts:
["foo", "bar"]
. This will be formatted either as a single line or an unordered list, depending on the length of the string. Example of the resulting Markdown:`foo`, `bar`
[("foo", ), ("bar", )]
. This will be formatted as an unordered list. Example of the resulting Markdown:
- `foo`
- `bar`
[("foo", "explanation of foo"), ("bar", "explanation of bar")]
. Example of the resulting Markdown:
- `foo`: explanation of foo
- `bar`: explanation of bar
examples
by moving them in json_schema_extra["examples": ...]
. It accepts all the formats that possible_values
accepts, plus a plain string, which won't be formatted on the output. If both examples
and json_schema_extra.examples
are present, json_schema_extra.examples
will be used.validation_alias
when used.Upgrade to pydantic
2.x. If you need to use pydantic 1.x, please use the 2.x
release of settings-doc
. New features will be available only in settings-doc
3.x and later, unless a backport is requested.
The upgrade changes couple of things in the pydantic
library that also need to be reflected in the templates:
pydantic.BaseSettings
is now pydantic_settings.BaseSettings
pydantic.Field
no longer accepts arbitrary **kwargs
. This has several implications for the Jinja2 templates:
field.field_info
is no longer available. All the attributes have moved to the field
object itself. For example field.field_info.description
is now field.description
.json_schema_extra
must be passed as a keyword argument and contain a dictionary. This is then available in the Jinja2 templates as field.json_schema_extra
instead of the previous field.field_info.extra
.The type of the field exposed to templates changed from ModelField
to FieldInfo
. This means that:
FieldInfo
no longer contain the name of the settings key. Therefore, fields
has been changed to list[tuple[str, FieldInfo]]
(instead of list[ModelField]
), where the str
value is name of the settings key. To iterate over the fields, use for env_name, field in fields
instead of for field in fields
.ModelField.type_
has changed to FieldInfo.annotation
.ModelField.required
has changed to FieldInfo.is_required()
.ModelField.default is not None
has changed to FieldInfo.default is not pydantic_core.PydanticUndefined
. A new helper function has_default_value(field)
has been added to the templates to make this easier to check.FieldInfo
type is typing.Literal
has been abstracted into helper function is_typing_literal
. The check is different for Python 3.8 and for later versions of Python.classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
validation_alias
when used.Upgrade to pydantic
2.x. If you need to use pydantic 1.x, please use the 2.x
release of settings-doc
. New features will be available only in settings-doc
3.x and later, unless a backport is requested.
The upgrade changes couple of things in the pydantic
library that also need to be reflected in the templates:
pydantic.BaseSettings
is now pydantic_settings.BaseSettings
pydantic.Field
no longer accepts arbitrary **kwargs
. This has several implications for the Jinja2 templates:
field.field_info
is no longer available. All the attributes have moved to the field
object itself. For example field.field_info.description
is now field.description
.json_schema_extra
must be passed as a keyword argument and contain a dictionary. This is then available in the Jinja2 templates as field.json_schema_extra
instead of the previous field.field_info.extra
.The type of the field exposed to templates changed from ModelField
to FieldInfo
. This means that:
FieldInfo
no longer contain the name of the settings key. Therefore, fields
has been changed to list[tuple[str, FieldInfo]]
(instead of list[ModelField]
), where the str
value is name of the settings key. To iterate over the fields, use for env_name, field in fields
instead of for field in fields
.ModelField.type_
has changed to FieldInfo.annotation
.ModelField.required
has changed to FieldInfo.is_required()
.ModelField.default is not None
has changed to FieldInfo.default is not pydantic_core.PydanticUndefined
. A new helper function has_default_value(field)
has been added to the templates to make this easier to check.FieldInfo
type is typing.Literal
has been abstracted into helper function is_typing_literal
. The check is different for Python 3.8 and for later versions of Python.classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
Upgrade to pydantic
2.x. If you need to use pydantic 1.x, please use the 2.x
release of settings-doc
. New features will be available only in settings-doc
3.x and later, unless a backport is requested.
The upgrade changes couple of things in the pydantic
library that also need to be reflected in the templates:
pydantic.BaseSettings
is now pydantic_settings.BaseSettings
pydantic.Field
no longer accepts arbitrary **kwargs
. This has several implications for the Jinja2 templates:
field.field_info
is no longer available. All the attributes have moved to the field
object itself. For example field.field_info.description
is now field.description
.json_schema_extra
must be passed as a keyword argument and contain a dictionary. This is then available in the Jinja2 templates as field.json_schema_extra
instead of the previous field.field_info.extra
.The type of the field exposed to templates changed from ModelField
to FieldInfo
. This means that:
FieldInfo
no longer contain the name of the settings key. Therefore, fields
has been changed to list[tuple[str, FieldInfo]]
(instead of list[ModelField]
), where the str
value is name of the settings key. To iterate over the fields, use for env_name, field in fields
instead of for field in fields
.ModelField.type_
has changed to FieldInfo.annotation
.ModelField.required
has changed to FieldInfo.is_required()
.ModelField.default is not None
has changed to FieldInfo.default is not pydantic_core.PydanticUndefined
. A new helper function has_default_value(field)
has been added to the templates to make this easier to check.FieldInfo
type is typing.Literal
has been abstracted into helper function is_typing_literal
. The check is different for Python 3.8 and for later versions of Python.classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
classes
of type Dict[Type[BaseSettings], List[ModelField]]
exposed to templates.tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
tasks
folder, in favour of delfino
.termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
termcolor
.--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
--class
option can be specified more than once and is also optional.pydantic.BaseSettings
inside a module with a new --module
option.generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
generate --templates
.generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
generate
sub-command.templates
for copying templates into selected folder.settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
settings-doc
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.
All notable changes to this project will be documented in this file.
The format is based on Keep a Changelog
and this project adheres to Semantic Versioning.
Types of changes are:
--update
to overwrite an existing file.--between
to update only a portion of a file specified by --update
, between two given marks.Add classifiers to the package.