athackst/mkdocs-simple-plugin

Build documentation files inside your code into a MkDocs site.

mkdocs-simple-plugin's Issues

Including a replacement to strip leading # for line-comment docs in Python disrupts h1s in """-string docs

I'm filing this as followup to the comment in the discussion in #94 about hacking around this sort of dilemma with a ===-style heading.

I am happy to volunteer some effort to iron this wrinkle out. But of course we'd need an agreeable mechanism to solve the underlying difficulty.

The difficulty appears to stem from trying to support both styles of documentation blocks in .py files simultaneously.

The first possible mechanism that comes to mind is to allow multiple different 'start' regexps, and then the one that matches determines what 'stop' and 'replace' regexps are used (with 'terminate' presumably being universal). Is that appealing? If so, then we'd need a comfortable syntax for specifying such a thing.
One option:

  semiliterate:
  - pattern: '\.py$'
    extraction:
    - start: '"""\smd'
      stop: '"""'
    - start: '#\smd'
      stop: '#\s/md'
      replace: ['^\s*#\s(.*\n?)$']
  - pattern: '\.(js|etc,etc)$'
    extraction:
    - start: '/\*\*\smd'
      stop: '\*\*/'

The second possible mechanism that comes to mind is to allow match groups of the start match to come into play in the replace regexps:

   semiliterate:
   - pattern: '\.py$'
     start: '^((\s*)"""\s|(\s*# ))md'
     replace: ['^\g<2>\g<3>(.*\n?)$']
     end: '^\s*("""|# /md)'

This would work because group 2 in the start match is any whitespace before """ if that's what matches and the empty string otherwise, and group 3 in the start match is any whitespace before the #, the # itself, and one space, if that's what matches, and the empty string otherwise. So the concatenation of them, which is what \g<2>\g<3> would expand to, is precisely the prefix that you would want to strip from all lines of the block up to the end trigger.

The second proposal is more intricate but briefer and has no effect on typical patterns that only have one set of start and end markers. The first proposal is easier on the eyes and mind but more verbose for all patterns, including ones that are not using the extra power.

You may have other ideas you'd like me to implement, or you may prefer to handle this yourself. All fine with me, just offering to help (particularly given my role in getting you into this mess. ;-)

Infinite reload loop in version 2.2.0

Hello,

Firstly, I would like to express my gratitude for the time and effort you have put into maintaining this package. I am writing to report an issue that I've run into. I have spent some time looking into this and believe that it may be a bug. However, I'm not sure, and I apologize in advance if this is user error. :)

Summary

I've been running into an issue in mkdocs-simple-plugin, but only in version 2.2.0, and not in 2.1.3.

Essentially, when you edit a file, mkdocs rebuilds the documentation, and it detects the rebuild as a change, and rebuilds again. This continues forever. Here's a log of what happens:

$ mkdocs serve
INFO     -  Building documentation...
INFO     -  mkdocs-simple-plugin: build_docs_dir: /tmp/mkdocs_simple_oz5xedz_
INFO     -  mkdocs-simple-plugin: /tmp/tmp.eRaappbCCQ/docs/.gitkeep/* --> /tmp/mkdocs_simple_oz5xedz_/.gitkeep/*
INFO     -  mkdocs-simple-plugin: .mkdocsignore --> /tmp/mkdocs_simple_oz5xedz_/.mkdocsignore
INFO     -  mkdocs-simple-plugin: README.md --> /tmp/mkdocs_simple_oz5xedz_/README.md
INFO     -  Cleaning site directory
INFO     -  Documentation built in 0.07 seconds
INFO     -  [17:50:11] Watching paths for changes: '/tmp/mkdocs_simple_oz5xedz_', 'mkdocs.yml', 'docs', '.mkdocsignore', 'README.md'
INFO     -  [17:50:11] Serving on http://127.0.0.1:8000/
< ---- Changed a file here
INFO     -  [17:50:14] Detected file changes
INFO     -  Building documentation...
INFO     -  mkdocs-simple-plugin: build_docs_dir: /tmp/mkdocs_simple_oz5xedz_
INFO     -  mkdocs-simple-plugin: /tmp/tmp.eRaappbCCQ/docs/.gitkeep/* --> /tmp/mkdocs_simple_oz5xedz_/.gitkeep/*
INFO     -  mkdocs-simple-plugin: .mkdocsignore --> /tmp/mkdocs_simple_oz5xedz_/.mkdocsignore
INFO     -  mkdocs-simple-plugin: README.md --> /tmp/mkdocs_simple_oz5xedz_/README.md
INFO     -  [17:50:14] Reloading browsers
INFO     -  [17:50:15] Detected file changes
INFO     -  Building documentation...
INFO     -  mkdocs-simple-plugin: build_docs_dir: /tmp/mkdocs_simple_oz5xedz_
INFO     -  mkdocs-simple-plugin: /tmp/tmp.eRaappbCCQ/docs/.gitkeep/* --> /tmp/mkdocs_simple_oz5xedz_/.gitkeep/*
INFO     -  mkdocs-simple-plugin: .mkdocsignore --> /tmp/mkdocs_simple_oz5xedz_/.mkdocsignore
INFO     -  mkdocs-simple-plugin: README.md --> /tmp/mkdocs_simple_oz5xedz_/README.md
INFO     -  [17:50:15] Reloading browsers
INFO     -  [17:50:15] Detected file changes
INFO     -  Building documentation...
INFO     -  mkdocs-simple-plugin: build_docs_dir: /tmp/mkdocs_simple_oz5xedz_
INFO     -  mkdocs-simple-plugin: /tmp/tmp.eRaappbCCQ/docs/.gitkeep/* --> /tmp/mkdocs_simple_oz5xedz_/.gitkeep/*
INFO     -  mkdocs-simple-plugin: .mkdocsignore --> /tmp/mkdocs_simple_oz5xedz_/.mkdocsignore
INFO     -  mkdocs-simple-plugin: README.md --> /tmp/mkdocs_simple_oz5xedz_/README.md
INFO     -  [17:50:15] Reloading browsers
INFO     -  [17:50:16] Detected file changes
INFO     -  Building documentation...

Debugging info

mkdocs.yml

I've reduced my config file down to the minimum which still triggers the problem.

site_name: site

plugins:
  - simple

Versions

• mkdocs: 1.4.2
• mkdocs-simple-plugin: 2.1.3 (working) 2.2.0 (not working)
• Python: 3.10.6
• OS: So far I have reproduced this problem on Ubuntu 22.04 and OSX.

Full reproduction case

I've made a repo with the above configuration, and a shell script which triggers the error. https://github.com/nickodell/mkdocs-inf-reload-reproducer

If I run it like this, it reloads once after the README file is changed.

./repro.sh 2.1.3

If I run it like this, after the script changes the README, it loops forever.

./repro.sh 2.2.0

Bisection

Bisecting the history between 2.1.3 and 2.2.0 finds that commit 40415a3 seems to the the commit which introduces this issue.

main branch/v2.1.0 apparently no longer accepts a single extract block

I am trying to update the mkdocs-semiliterate plugin built on mkdocs-simple to v2.1.0 and/or to the main branch (as you may recall, I prefer the plugin to itself explicitly extract from other files when producing documentation, rather than having the processing of those other files result in the creation of "snippet" files by side effect which are then included in the produced documentation by another mechanism -- hence I published mkdocs-semiliterate).

However, some of my tests now fail with

ERROR    -  Config value: 'plugins'. Error: Plugin 'semiliterate' value:
            'semiliterate'. Error: Sub-option 'extract' configuration error:
            Expected a list of items, but a <class 'dict'> was given.

The relevant section of an mkdocs.yml where this happens is

    semiliterate:
      - pattern: '\.py$'
        extract: {start: '"""\smd', stop: '"""'}
      - pattern: '.drone.yml'
        destination: 'drone_develop.md'
        extract:
          start: '### develop'
          stop: '^\s*###'
          replace: ['^# (.*\s*)$', '^\s*-(.*\s*)$']

(As you can see, each of these file patterns has just one extract block.)
The documentation for v2.1.0 still claims that a single block rather than a list of blocks is permitted, and there is still a line of code in the class Semiliterate constructor to handle this:

        if isinstance(extract, dict):
            # if there is only one extraction pattern, allow it to be a single
            # dict entry
            extract = [extract]

but I believe the new more-elaborated configuration schema for the plugin is causing mkdocs to reject semiliterate parameters with just one block rather than a list of them before the Semiliterate code ever gets to processing the extract parameter, cf. lines 181-190 of plugin.py:

    # #### extract
    #
    # This parameter determines what will be extracted from a scanned
    # file that matches the pattern above. Its value should be a block
    # or list of blocks of settings.
    #
    # {% include "mkdocs_simple_plugin/extract_config.snippet" %}
    extract = config_options.Optional(config_options.ListOfItems(
        config_options.SubConfig(ExtractConfig)))
    #

I don't think the config schema in the code actually allows for both the "block or list of blocks" possibilities in the doc comments just above the code.

Would you like me to try to generate a PR to restore accepting just a block of settings rather than a list of them? Or do you prefer to handle this yourself?

New to MkDocs: no output from plugin

I read the instructions multiple times, but I can't get my code to be parsed.
I have it placed as a subfolder of docs

mkdocs.yml
docs/
│   code/  
│   README.md
│   ...

mkdocs.yml is the bare minimum:

site_name: KDB
plugins:
  - simple: null
  - search: null
theme: readthedocs
extra_css:
  - css/extra.css

The only output from mkdocs is:

INFO - mkdocs-simple-plugin: build_docs_dir: C:\Users\luca\AppData\Local\Temp\mkdocs_simple_KDB4qzegjlc

The C:\Users\luca\AppData\Local\Temp\mkdocs_simple_KDB4qzegjlc\code folder contains a verbatim copy of the contents of the original. Is that the expected output?

Invalid config options

Incremental file building when --dirtyreload is set

Hey there,

I've been playing around with this plugin recently and have noticed some significant performance issues related to live reloading. The performance of the plugin is perfectly acceptable for a single documentation build, but it appears that any file change while this plugin is active leads the plugin to rebuild all files that it's watching.

I've played around with the code a bit, and I think it's relatively easy to:

• Know when the user has --dirtyreload set (from the MkDocsConfiguration)
• Track the most recent build that mkdocs-simple performed (e.g., using a global within plugin.py, although there may be a better way to do this)
• Filter the list of files that will be operated on by the plugin in both merge_docs and build_docs in simple.py

The one thing I haven't been able to figure out is something that's going on under the hood leading to this error (during the build step):

[Errno 2] No such file or directory: <file that was not changed>

So it seems like something is expecting this file to be output, but I haven't been able to tell what.

Given this, two questions for you:

1. If we can figure out how to make this work, would you be willing to merge a change like this assuming I can make it reasonable
2. If so, could you please point me in the right direction to complete this?

Thanks!

Divergence between docs and commands for testing changes to plugin code

The "Developing" documentation page, currently generated from mkdocs_simple_plugin/README.md, specifies the test commands tests/integration/test.bats and tests/test_flake8.sh but the actual tests are tests/test.bats and tests/test_lint.sh, respectively.

I would be happy to submit a pull request to align. However, my recommendation would be to move the Developing markdown, or at least the testing portion of it, to .github/workflows/test.yml where the testing is actually performed, and ideally ensure the extraction is such that the actual code lines that perform the tests are the ones that end up in the documentation page, to make certain that through any future development that the documentation and reality coincide. (From my point of view, that guarantee of correspondence is one of the key added values of a documentation scheme like that of simple.)

Please advise how you'd like things to proceed here.

TypeError: 'Files' object is not subscriptable when using mkdocs 1.6.0 and simple plugin with merge_docs_dir: false

Mkdocs serve fails with mkdocs 1.6.0 and simple plugin with merge_docs_dir: false

This error does not occur with mkdocs versions prior to 1.6.0. The issue seems to be related to the Files object handling in the mkdocs-simple-plugin when the merge_docs_dir parameter is set to false.

As a temporary workaround, reverting to an earlier version of mkdocs or setting merge_docs_dir to true avoids the error.

Steps to Reproduce:

Set up an mkdocs project with mkdocs version 1.6.0.
Install and configure the mkdocs-simple-plugin.
Set the merge_docs_dir configuration parameter to false in the mkdocs.yml file.
Run the mkdocs serve command.

Expected Behavior:

The mkdocs server should start without any errors, and the site should be accessible for preview.

Actual Behavior:

node@backstage-docker:/app$ mkdocs --version
mkdocs, version 1.6.0 from /usr/local/lib/python3.9/dist-packages/mkdocs (Python 3.9)
node@backstage-docker:/app$ mkdocs serve
INFO    -  DeprecationWarning: warning_filter doesn't do anything since
           MkDocs 1.2 and will be removed soon. All messages on the
           `mkdocs` logger get counted automatically.
             File
           "/usr/local/lib/python3.9/dist-packages/mkdocs_monorepo_plugin/parser.py",
           line 22, in <module>
               from mkdocs.utils import yaml_load, warning_filter,
           dirname_to_title, get_markdown_title
             File
           "/usr/local/lib/python3.9/dist-packages/mkdocs/utils/__init__.py",
           line 403, in __getattr__
               warnings.warn(
INFO    -  Building documentation...
INFO    -  mkdocs-simple-plugin: build_dir: /tmp/mkdocs_simple_xgfrtozg
INFO    -  Cleaning site directory
INFO    -  mkdocs-simple-plugin: Added README.md
INFO    -  mkdocs-simple-plugin: Added CHANGELOG.md
INFO    -  DeprecationWarning: Do not access Files._files.
             File
           "/usr/local/lib/python3.9/dist-packages/mkdocs_simple_plugin/plugin.py",
           line 376, in on_files
               for file in files._files[:]:
             File
           "/usr/local/lib/python3.9/dist-packages/mkdocs/structure/files.py",
           line 172, in _files
               warnings.warn("Do not access Files._files.",
           DeprecationWarning)
Traceback (most recent call last):
  File "/usr/local/bin/mkdocs", line 8, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1157, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1078, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1688, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 1434, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.9/dist-packages/click/core.py", line 783, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/mkdocs/__main__.py", line 268, in serve_command
    serve.serve(**kwargs)
  File "/usr/local/lib/python3.9/dist-packages/mkdocs/commands/serve.py", line 85, in serve
    builder(config)
  File "/usr/local/lib/python3.9/dist-packages/mkdocs/commands/serve.py", line 67, in builder
    build(config, serve_url=None if is_clean else serve_url, dirty=is_dirty)
  File "/usr/local/lib/python3.9/dist-packages/mkdocs/commands/build.py", line 292, in build
    files = config.plugins.on_files(files, config=config)
  File "/usr/local/lib/python3.9/dist-packages/mkdocs/plugins.py", line 593, in on_files
    return self.run_event('files', files, config=config)
  File "/usr/local/lib/python3.9/dist-packages/mkdocs/plugins.py", line 566, in run_event
    result = method(item, **kwargs)
  File "/usr/local/lib/python3.9/dist-packages/mkdocs_simple_plugin/plugin.py", line 376, in on_files
    for file in files._files[:]:
TypeError: 'Files' object is not subscriptable

mkdocs.yml:

site_name: 'Backstage Documentation'
repo_url: https://...
edit_uri: edit/main

nav:
  - README: README.md 
  - CHANGELOG: CHANGELOG.md
plugins:
  - techdocs-core
  - simple:
      folders: ["./CHANGELOG.md", "./README.md"]
      merge_docs_dir: false

Demonstrate usage in this site

Seems incredible to use a conventional mkdocs layout with such a simple site rather than demonstrating the plugin. A GitHub wiki is also a good example of a site that is too simple for [won't actually allow] a docs directory.

Divergence between docs and behavior for "replace" parameter

As of mkdocs 0.5.0, the documentation at https://allisonthackston.com/mkdocs-simple-plugin/mkdocs_simple_plugin/plugin/
states with respect to the "replace" parameter that "If none [of the replace patterns] match, the line is transcribed unchanged." However the code now has the behavior that if the "replace" parameter is specified and none of the patterns match, the line is dropped.

I would be happy to file a pull request to align the two, but would need direction as to whether the documentation should be changed to reflect the changed behavior, or the behavior should be restored to match the documentation.

Using MkDocs from Github Actions with Material - Plugins not enabled?

Hi, first time posting here in Github Issues.

I have managed to use MkDocs & Material via Github Actions to publish a website to Github pages.
And I will freely admit that I'm very dangerous and chiefly code with a chainsaw and sledge hammer...

What I'm finding difficult to understand is how the Plugins work?
In my Github workflow I have understood enough to install plugins via pip here:
MakeDocsAction.yaml
But also curious as to whether or not I should be just able to "add" these to the list via the requirements.txt file?
requirements.txt

Anyway - getting them installed is one thing, easy enough, the hard part that I'm struggling with is getting them enabled?
See here for the mkdocs.yml in root:
mydocs.yml

The only ones I can get running are Search, Simple & Macros - am I doing something really dumb?
Snippet:

# Plugins
plugins:
  - search
  - simple
  #- techdocs-core
  #- glightbox
  #- social
  #- awesome-list
  #- table-reader
  #- img2fig
  #- mermaid2
  - macros
  # - minify

I've commented out the Plugins that keep erroring - here is an example of the error "Action"
Action run - with error

I've simply not worried about the Plugins errors and got on with creating the content and figured I'd get around to this at some stage.

Using pip I can consistently get the plugin to "install" but getting it enabled has consistently shown an error similar to this with just the name of the plug-in changing.

I figured it was just me doing something dumb?

semiliterate destination using pattern with no matching group crashes

If a semiliterate block is specified with a destination that does not depend on the pattern match and the pattern parameter does not have a matching group, mkdocs crashes. Such parameters can be legitimately useful, as in:

  semiliterate:
  - pattern: 'LICENSE'
    destination: 'LICENSE.md'
    start: 'TERMS'

or in general, this idiom can be used if necessary to rename a specific project file in the generated documentation site.
In any case, such parameter settings should not cause a crash. Full disclosure: I wrote this bug -- my apologies! I will post a pull request fixing it momentarily.

Error when using files from root and from docs folder

First thanks for your great plugin and all the work you put into it.

We're experiencing a problem when using files from the root dir like the README.md and files from the docs dir like docs/test.md.

Our folder structure looks like this:

├── README.md
├── CHANGELOG.md
├── docs
│   └── test.md
└── mkdocs.yml

The mkdocs.yml looks like this:

edit_uri: edit/main

nav:
  - Home: README.md 
  - Changelog: CHANGELOG.md
  - Test: docs/test.md

plugins:
  - simple:
      folders: ["docs/**", "./CHANGELOG.md", "./README.md"]
      merge_docs_dir: false

We needed to set merge_docs_dir to false to be able to specify the test docs like this docs/test.md in the nav section. This was the only way we could get the edit_uri to work properly (if there is another way please let me know).

By setting merge_docs_dir to false the docs get rendered correctly and the edit_uri works as expected. The problem is now, that mkdocs prints out this info message during the build:

INFO    -  The following pages exist in the docs directory, but are not included in the "nav" configuration:
             - docs/test.md

- The plugin copies the README and the CHANGELOG additionaly into the docs dir, which is not necessary because it's already in the root dir. (My bad, I had copied the README and CHANGELOG into the docs folder)

• I don't understand whys mkdocs thinks that the docs/test.md is not included in the nav section. It is included and it gets rendered correctly. I assume it has something to do with the docs_dir that the simple plugin is setting?!

This is a bit confusing for our users. Is there a way to fix this?

v2.1.1 no longer seems to ignore_folders

Again in the process of attempting to update mkdocs_semiliterate, this time to v2.1.1 (which is OK with a single extract block, thanks), I am finding that if I for example have 'tests' in my ignore_folders parameter, files in my tests/ directory are still being scanned. The change seems to be that in prior code, the file tree was walked in Simple.build_docs and the loop included the line:

                directories[:] = [
                    d for d in directories if not self.is_ignored(root, d)]

but now the file tree is walked in Simple.get_files and the apparently corresponding loop has no filter on directories. Please let me know how I can assist with this situation.

Divergence between docs and behavior for "start" parameter

As of mkdocs 0.5.0, the documentation at https://allisonthackston.com/mkdocs-simple-plugin/mkdocs_simple_plugin/plugin/ states with respect to the "start" parameter that "the (last) extraction mode (if any) with no start parameter is active beginning with the first line of the scanned file; there is no way such a mode can be reactivated if it stops."

However, the behavior is actually that an extraction mode with no start parameter is activated after any line is reached where no mode is active and no earlier extraction pattern is activated by that line. That means that such an extraction mode is only active starting with the second line of a file, and moreover that once it stops, it will always be reactivated after skipping a line. Hence it is no longer useful for "front-matter extraction" (as also mentioned in the documentation).

Again, I would be happy to file a PR including an appropriate test of the behavior. In this case, I'd like to urge restoration of the documented behavior, as the altered behavior seems less useful, can be obtained without the "no start pattern" convention simply by using a start pattern of '.', and there does not seem to be any simple way of supporting "front-matter extraction" without the convention as it is documented. One can make an extraction mode that will match any first line of a file and emit it, but then that pattern will immediately restart right after stopping, since its start pattern has to be designed to match anything.

Bumps [actions/setup-python](https://github.com/actions/setup-python) from 2.2.2 to 2.3.0.

Make GitHub workflow support caching

Bumps actions/setup-python from 2.2.2 to 2.3.0.

Release notes

Sourced from actions/setup-python's releases.

Support caching dependencies

This release introduces dependency caching support (actions/setup-python#266)

Caching dependencies.

The action has a built-in functionality for caching and restoring pip/pipenv dependencies. The cache input is optional, and caching is turned off by default.

Besides, this release introduces dependency caching support for mono repos and repositories with complex structure.

By default, the action searches for the dependency file (requirements.txt for pip or Pipfile.lock for pipenv) in the whole repository. Use the cache-dependency-path input for cases when you want to override current behaviour and use different file for hash generation (for example requirements-dev.txt). This input supports wildcards or a list of file names for caching multiple dependencies.

Caching pip dependencies:

steps:
- uses: actions/checkout@v2
- uses: actions/setup-python@v2
  with:
    python-version: '3.9'
    cache: 'pip'
- run: pip install -r requirements.txt
- run: pip test

Caching pipenv dependencies:

steps:
- uses: actions/checkout@v2
- name: Install pipenv
  run: pipx install pipenv
- uses: actions/setup-python@v2
  with:
    python-version: '3.9'
    cache: 'pipenv'
- run: pipenv install
- run: pipenv test

Change dependency file:

steps:
- uses: actions/checkout@v2
- uses: actions/setup-python@v2
  with:
    python-version: '3.9'
    cache: 'pip'
    cache-dependency-path: '**/requirements-dev.txt'
- run: pip install -r subdirectory/requirements-dev.txt
- run: pip test

Commits

• 0066b88 Add a workflow to release a new version of the action (#274)
• 280924f Implementation of python's caching (#266)
• 52636cf Fix consistency in README (#250)
• ca5c590 Update version for setup-python in package.json (#264)
• feeaa3b Add issue and pull request templates (#258)
• 002b1e4 Change python version for pypy in workflow files (#259)
• d12543a Merge pull request #252 from dmitry-shibanov/v-dmshib/update-dependencies
• 4aa563b update dependencies
• 70e2063 Update test-python.yml (#246)
• 2d803e7 Create check-dist.yml (#236)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Originally posted by @dependabot in #237

Files in docs_dir being copied to nested dir

Thank you for building such a useful plugin :)

I've run into some issue with files in docs directory being copied incorrectly.

The setup I'm using is:

mac os,
python 3.8.5
mkdocs 1.1.2
mkdocs_simple_plugin 0.1.8

My repo structure looks like:

├── charts
  ├── chart A
    └── README.md
  └── chart B
    └── README.md
├── docs
  ├── index.md
  └── FAQ.md
└── mkdocs.yaml

mkdocs.yaml:

site_name: foo

theme:
  name: material
plugins:
  - simple:
      include_folders:
        - "./charts/*"

docs_dir: docs
use_directory_urls: false

nav:
  - About: index.md
  - Charts:
    - chart A: charts/chart A/README.md
    - chart B: charts/chart B/README.md
  - FAQ: FAQ.md

While reading through the code, I noticed this specific line is related to the issue I'm seeing. Is this an intended behavior?

Error: The path [...]/docs isn't an existing directory

I am very afraid that I am asking a question whose answer should be obvious; maybe I am just being thick, and if so my apologies. In any case, it seems perfectly natural to me that using simple, one would not have a docs_dir at all. I started using simple with my project, and I ran the simple generator, and created my docs files in among my source, and then when I went to build the docs, I got the error that is the title of this issue. To get it running, I just set the docs_dir in the mkdocs.yml to dummy, and created an empty directory named dummy. But it looks sort of stupid to check that in, so I wanted to dig a bit deeper, and could not find a clean way to avoid this error.

Anyhow, I went so far as to clone the mkdocs-simple-plugin repository itself, and out of the box, try mkdocs build, and lo and behold: exactly the same error. Yet clearly you build your own documentation with mkdocs. So all this emboldened me to create this issue, which is really more of a question (sorry again, but I couldn't think what else to do): Pray tell, how do you avoid the dread "isn't an existing directory" error? Thank you so much.