Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using mdbook build some_dir, preprocessor using relative path doesn't work #2289

Closed
Lorak-mmk opened this issue Jan 11, 2024 · 1 comment
Labels
C-bug Category: A bug, incorrect or unintended behavior

Comments

@Lorak-mmk
Copy link

Problem

If I use a preprocessor written in Python, like in documentation example: https://rust-lang.github.io/mdBook/format/configuration/preprocessors.html#provide-your-own-command , it works correctly when I execute mdbook build - so the book.toml file is in the same directory.
In the project I'm working on, book is in the docs subdirectory, so it's usually built with mdbook build docs. But when using this custom preprocessor, it doesn't work when invoked like this, because the PWD is still the main directory, instead of docs directory.
This is counterintuitive and limits the ability to use preprocessors.

I created a workaround in the project ( scylladb/scylla-rust-driver#910 ):

[preprocessor.sphinx]
command = '''bash -c '
if test -f "./docs/sphinx_preprocessor.py"; then
    python ./docs/sphinx_preprocessor.py "$@" 
else 
    python ./sphinx_preprocessor.py "$@"
fi' run_preprocessor
'''

but it's ugly and only allows executing from root or docs directories.

Steps

  1. Have some book in a directory foo.
  2. Create a preprocessor called bar.py in foo directory.
  3. Add entry to book.toml:
[preprocessor.bar]
command = "python bar.py"
  1. Go to parent of foo directory
  2. Execute mdbook build foo
  3. Book is built, but without using preprocessor, as bar.py couldn't be found.

Possible Solution(s)

Before executing preprocessor command change the PWD to the root of the book

Notes

No response

Version

mdbook v0.4.36
@Lorak-mmk Lorak-mmk added the C-bug Category: A bug, incorrect or unintended behavior label Jan 11, 2024
@ehuss
Copy link
Contributor

ehuss commented Jan 11, 2024

Thanks for the report! I believe this is a duplicate of #1424, so closing in favor of that.

@ehuss ehuss closed this as not planned Won't fix, can't repro, duplicate, stale Jan 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: A bug, incorrect or unintended behavior
Projects
None yet
Development

No branches or pull requests

2 participants