fix: All docs references to silence warning

dynaconf · pedro-psb · Feb 26, 2024 · Feb 25, 2024 · Feb 25, 2024 · Feb 25, 2024
commit 5cf3a68e08204617ebe0f342d726fe1fd1c03bbf
diff --git a/docs/advanced.md b/docs/advanced.md
@@ -79,7 +79,7 @@ settings = Dynaconf(post_hooks=hook_function)
 ```
 
 You can also set the merging individually for each settings variable as seen on
-[merging](/merging/) documentation.
+[merging](merging.md) documentation.
 
 ## Inspecting History
 
@@ -89,7 +89,7 @@ You can also set the merging individually for each settings variable as seen on
     This feature is in **tech preview** the usage interface and output format is
     subject to change.
 
-This feature purpose is to allow tracking any config-data loading history, that is, the loading steps that lead to a given final value. It can return a dict data report, print to `stdout` or write to a file, and is also available as a [CLI command](/cli#dynaconf-inspect-tech-preview).
+This feature purpose is to allow tracking any config-data loading history, that is, the loading steps that lead to a given final value. It can return a dict data report, print to `stdout` or write to a file, and is also available as a [CLI command](cli.md#dynaconf-inspect-tech-preview).
 
 It works by setting a *SourceMetadata* object to every ingested data, so it can be recovered and filtered to generate meaningful reports. The properties of this object are:
 
@@ -287,7 +287,7 @@ if __name__ == "__main__":
 You can load files from within a python script.
 
 When using relative paths, it will use `root_path` as its basepath.
-Learn more about how `root_path` fallback works [here](/configuration#root_path).
+Learn more about how `root_path` fallback works [here](configuration.md#root_path).
 
 ```python
 from dynaconf import Dynaconf
@@ -511,7 +511,7 @@ all_settings = settings.from_env('development', keep=True).from_env('other', kee
 
 The variables from [development] are loaded keeping pre-loaded values, then the variables from [other] are loaded keeping pre-loaded from [development] and overriding it.
 
-It is also possible to pass additional [configuration](/configuration/) variables to `from_env` method.
+It is also possible to pass additional [configuration](configuration.md) variables to `from_env` method.
 
 ```py
 new_settings = settings.from_env('production', keep=True, SETTINGS_FILE_FOR_DYNACONF='another_file_path.yaml')
@@ -590,7 +590,7 @@ assert obj.VALUE == 42.1  # AttributeError
 
 ## Exporting
 
-You can generate a file with current configs by calling `dynaconf list -o /path/to/file.ext` see more in [cli](/cli/)
+You can generate a file with current configs by calling `dynaconf list -o /path/to/file.ext` see more in [cli](cli.md)
 
 You can also do that programmatically with:
 

diff --git a/docs/cli.md b/docs/cli.md
@@ -9,7 +9,7 @@ Every command (except the init) will require the Instance can be set using `-i`
 
 The `$ dynaconf -i config.settings` cli provides some useful commands
 
-> **IMPORTANT** if you are using [Flask Extension](/flask/) the env var `FLASK_APP` must be defined to use the CLI, and if using [Django Extension](/django/) the `DJANGO_SETTINGS_MODULE` must be defined.
+> **IMPORTANT** if you are using [Flask Extension](flask.md) the env var `FLASK_APP` must be defined to use the CLI, and if using [Django Extension](django.md) the `DJANGO_SETTINGS_MODULE` must be defined.
 
 ### dynaconf --help
 
@@ -66,7 +66,7 @@ as well as `.gitignore` file ignoring the generated `.secrets.toml`
 .secrets.*
 ```
 
-> For sensitive data in production is recommended using [Vault Server](/secrets/)
+> For sensitive data in production is recommended using [Vault Server](secrets.md)
 
 ```bash
 Usage: dynaconf init [OPTIONS]
@@ -113,7 +113,7 @@ Note that `-i`/`--instance` cannot be used with `init` as `-i` must point to an
 
 Inspect and dump data's loading history about a specific key or environment.
 
-It is also available as a [utility function](/advanced#inspecting-history).
+It is also available as a [utility function](advanced.md#inspecting-history).
 
 ```
 Usage: dynaconf inspect [OPTIONS]

diff --git a/docs/configuration.md b/docs/configuration.md
@@ -102,7 +102,7 @@ other_value = "other value from dev"
 ...     default_env="my_default",
 ...     env="development", # this is the active env, by default
 ... )
- 
+
 >>> settings.other_value
 "other value from dev"
 
@@ -111,7 +111,7 @@ other_value = "other value from dev"
 ```
 
 !!! note
-		The `default_env` is not the environment that will be active on startup. For this, see [`env`](/configuration/#env).
+		The `default_env` is not the environment that will be active on startup. For this, see [`env`](configuration.md#env).
 
 
 ---
@@ -272,7 +272,7 @@ After loading the files specified in `settings_files` dynaconf will load all the
 Note that:
 
 - Globs are allowed
-- When relative paths are given it will use [root_path](/configuration#root_path) as their basedir.
+- When relative paths are given it will use [root_path](configuration.md#root_path) as their basedir.
 - If `root_path` is not defined explicitly, will fallback to the directory of the last loaded setting or
 to the `cwd`. Eg:
 
@@ -310,12 +310,12 @@ Dynaconf(includes="extra.yaml")
 > env-var=`LOADERS_FOR_DYNACONF`
 
 The list of loaders dynaconf will trigger after its core loaders, this list is useful to include
-[custom loaders](/advanced/#custom loaders) and also to control the loading of env vars as the last step.
+[custom loaders](advanced.md/#custom loaders) and also to control the loading of env vars as the last step.
 
 !!! warning
     By default the `env_loader` will be latest on this list, so it ensures environment variables has the priority following the Unix philosophy.
 
-Learn more about [loaders](/advanced/)
+Learn more about [loaders](advanced.md)
 
 ---
 
@@ -364,7 +364,7 @@ With `merge_enabled` the ending `settings.server` will be
 {"port": 8888, "address": "server.com"}
 ```
 
-Otherwise it will be only what is specified in the latest loaded file. read more about [merging strategies](/merging)
+Otherwise it will be only what is specified in the latest loaded file. read more about [merging strategies](merging.md)
 
 ---
 
@@ -373,7 +373,7 @@ Otherwise it will be only what is specified in the latest loaded file. read more
 > type=`str`, default=`"__"` (double underescore) </br>
 > env-var=`NESTED_SEPARATOR_FOR_DYNACONF`
 
-One of the [merging strategies](/merging) is the use of `__` to access nested level data structures. By default the separator is `__` (double underline), this variable allows you to change that.
+One of the [merging strategies](merging.md) is the use of `__` to access nested level data structures. By default the separator is `__` (double underline), this variable allows you to change that.
 
 ex:
 
@@ -452,7 +452,7 @@ Note that:
     - The place of the last loaded file, if any files were already loaded
     - CWD
 
-Read more on [settings_files](/settings_files/#load).
+Read more on [settings_files](settings_files.md#load).
 
 !!! note
      The `cwd` is from where the python interpreter was called.
@@ -508,7 +508,7 @@ export SETTINGS_FILE_FOR_DYNACONF="/etc/program/settings.toml"
 export SETTINGS_FILES_FOR_DYNACONF="/etc/program/settings.toml;/tmp/foo.yaml"
 ```
 
-Read more on [settings_files](/settings_files/) </br>
+Read more on [settings_files](settings_files.md) </br>
 
 ---
 
@@ -574,7 +574,7 @@ settings.get("user") # won't try loading unprefixed USER
 
 Defines if validation will be triggered when a Dynaconf instance
 is updated with the methods `update()`, `set()` or `load_file()`.
-Also defines which raising strategy will be used (see more on [Validation](/validation/#trigger-on-data-update)).
+Also defines which raising strategy will be used (see more on [Validation](validation.md#trigger-on-data-update)).
 
 Valid options are:
 
@@ -618,7 +618,7 @@ validators=[
 
 When `envs` is enabled, defines if validation will be performed only on `default` + `current_env` or if all envs will be validated (even if not activated).
 
-Setting this to `True` can be useful if you have validators that apply only to some `env`s, like requiring a setting in `production` but not in `development`. See [this section](/validation#validating-only-the-current_env) in the Validation page.
+Setting this to `True` can be useful if you have validators that apply only to some `env`s, like requiring a setting in `production` but not in `development`. See [this section](validation.md#validating-only-the-current_env) in the Validation page.
 
 ### **validate_only**
 
@@ -630,7 +630,7 @@ This setting only applies during `Dynaconf` instantiation. Further calls to `Dyn
 
 In practice, this forwards `validate_only` to the `only` kwarg during the validation step upon `Dynaconf` instantiation for all `Validator`s passed. Note that this setting has interaction with [`validate_exclude`](#validate_exclude).
 
-Read more about it in the [selective validation](/validation#selective-validation) section.
+Read more about it in the [selective validation](validation.md#selective-validation) section.
 
 ### **validate_exclude**
 
@@ -642,7 +642,7 @@ This setting only applies during `Dynaconf` instantiation. Further calls to `Dyn
 
 In practice, this forwards `validate_exclude` to the `exclude` kwarg during the validation step upon `Dynaconf` instantiation for all `Validator`s passed. Note that this setting has interaction with [`validate_only`](#validate_only).
 
-Read more about it in the [selective validation](/validation#selective-validation) section.
+Read more about it in the [selective validation](validation.md#selective-validation) section.
 
 ---
 
@@ -674,7 +674,7 @@ default = {
 }
 ```
 
-Read more on [Secrets](/secrets/)
+Read more on [Secrets](secrets.md)
 
 ---
 

diff --git a/docs/django.md b/docs/django.md
@@ -104,7 +104,7 @@ In the root directory (the same where `manage.py` is located) put your `settings
 To switch the working environment the `DJANGO_ENV` variable can be used, so `DJANGO_ENV=development` to work
 in development mode or `DJANGO_ENV=production` to switch to production.
 
-If you don't want to manually create your config files take a look at the [CLI](/cli/)
+If you don't want to manually create your config files take a look at the [CLI](cli.md)
 
 !!! tip
     **.yaml** is the recommended format for Django applications because it allows easily writing complex data structures. Nevertheless, feel free to choose any format you are familiar with.
@@ -155,7 +155,7 @@ Your settings are now read from `/etc/projectname/settings.toml` (dynaconf will
 
 You can have additional settings read from `/etc/projectname/plugins/*` any supported file from this folder will be loaded.
 
-You can set more options, take a look at [configuration](/configuration/)
+You can set more options, take a look at [configuration](configuration.md)
 
 ### Use Django functions inside custom settings
 
@@ -164,7 +164,7 @@ converters with the `add_converters` utility.
 
 When defining those in `settings.py`, there are some django functions that can't
 be imported directly in the module scope. Because of that, you may add them in
-a [hook](/advanced#hooks) that executes after loading.
+a [hook](advanced.md#hooks) that executes after loading.
 
 For example, if you need to use `reverse_lazy`, you might do this:
 

diff --git a/docs/envvars.md b/docs/envvars.md
@@ -6,14 +6,14 @@ According to [12factorapp](https://12factor.net) it is a good practice to keep y
 
 In addition to that Dynaconf offers some approaches you may want to **Optionally** follow:
 
-- Add a list of validators to `validators=[Validator()]` on your dynaconf settings instance and provide [defaults and constraints](/validation/).
+- Add a list of validators to `validators=[Validator()]` on your dynaconf settings instance and provide [defaults and constraints](validation.md).
 - Enable `load_dotenv` and provide a `.env.example` or `.env` file with the default variables.
-- Write your variables in a [settings file](/settings_files) in the format of your choice.
-- Load your settings from [vault or redis](/secrets/)
+- Write your variables in a [settings file](settings_files.md) in the format of your choice.
+- Load your settings from [vault or redis](secrets.md)
 
 ## Environment variables
 
-You can override any setting key by exporting an environment variable prefixed by `DYNACONF_` (or by the [custom prefix](/configuration/#envvar_prefix)).
+You can override any setting key by exporting an environment variable prefixed by `DYNACONF_` (or by the [custom prefix](configuration.md/#envvar_prefix)).
 
 !!! warning
     Dynaconf will only look for UPPERCASE prefixed envvars. This means envvar exported as `dynaconf_value` or `myprefix_value` won't be loaded, while `DYNACONF_VALUE` and `MYPREFIX_VALUE` (when proper set) will.
@@ -33,9 +33,9 @@ export DYNACONF_STRING_NUM="'76'"                            # str: "76"
 export DYNACONF_PERSON__IS_ADMIN=true                        # bool: True (nested)
 ```
 
-!!! info 
+!!! info
     For envvars Dynaconf will automatically transform `True` and `False` to `true` and `false` respectively,
-    this transformation allows TOML to parse the value as a boolean.  
+    this transformation allows TOML to parse the value as a boolean.
     If you want to keep the original value in this case use `@str` or wrap it in quotes twice like `FOO='"True"'`
     Note that this applies only for strictly string equal to `True|False` doesn't apply to same string found
     inside toml data structures.
@@ -64,7 +64,7 @@ assert settings.STRING_NUM == "76"
     **Also variable access is case insensitive for the first level key**
 
 !!! warning
-    When exporting data structures such as `dict` and `list` you have to use one of:  
+    When exporting data structures such as `dict` and `list` you have to use one of:
     ```
     export DYNACONF_TOML_DICT={key="value"}
     export DYNACONF_TOML_LIST=["item"]
@@ -154,7 +154,7 @@ export PREFIX_PATH='@jinja {{env.HOME}}/.config/{{this.DB_NAME}} | abspath'
 ### Adding a Custom Casting Token
 
 If you would like to add a custom casting token, you can do so by adding a
-converter. For example, if we would like to cast strings to a pathlib.Path 
+converter. For example, if we would like to cast strings to a pathlib.Path
 object we can add in our python code:
 
 ```python

diff --git a/docs/faq.md b/docs/faq.md
@@ -71,7 +71,7 @@ See more about [hooks](https://www.dynaconf.com/advanced/#hooks)
 
 > I use some django utility functions in my django `settings.py`. Can I still use them if I choose to use `yaml` to manage my config?
 
-Yes, you may add a custom converter for any functions you like. Refer [here](/django/#use-django-functions-inside-custom-settings) for a full example.
+Yes, you may add a custom converter for any functions you like. Refer [here](django.md#use-django-functions-inside-custom-settings) for a full example.
 
 ## Default-override workflow
 
@@ -104,8 +104,8 @@ bucket=["a", "b", "c", "d"]
 bucket=["a", "b", "c", "d"]
 ```
 
-To control how you want to merge these structures, you may want to have a look at [merging](/merging/)
-There are several ways you can merge data: settings the global option [merge_enabled](/configuration/#merge_enabled), using dunder syntax or marking a whole file, a specific env, or just an option for merging. Choose what fits best for your case.
+To control how you want to merge these structures, you may want to have a look at [merging](merging.md)
+There are several ways you can merge data: settings the global option [merge_enabled](configuration.md/#merge_enabled), using dunder syntax or marking a whole file, a specific env, or just an option for merging. Choose what fits best for your case.
 
 ## Error with Pyinstaller executable
 

diff --git a/docs/flask.md b/docs/flask.md
@@ -62,7 +62,7 @@ in development mode or `FLASK_ENV=production` to switch to production.
 
 > **IMPORTANT**: To use `$ dynaconf` CLI the `FLASK_APP` must be defined.
 
-IF you don't want to manually create your config files take a look at the [CLI](/cli/)
+IF you don't want to manually create your config files take a look at the [CLI](cli.md)
 
 ## Loading Flask Extensions Dynamically