Skip to content

Conversation

DiscoStarslayer
Copy link

Generally with mkdocs you can exclude the link to the code repository by omitting the repo_url from the mkdocs.yml file.

This does work in most cases. One exception to this is if you also have a edit_uri config value.

We have a MKDoc page where we don't specifically want to point a user to a specific repo, but we do want to encourage contributions to the docs.

If we provide an explicit edit_uri like edit_uri: https://github.com/mkdocs/mkdocs/blob/master/docs/ this works as expected even without a repo_url.

But, because of some logic in config_options.py and with this configuration, repo_url ends up being "/" which causes our theme to include empty whitespace where the repo link should be (see screenshots).

Screen Shot 2019-10-02 at 4 50 31 PM

66017065-3288ac80-e4a7-11e9-8887-d1987d0332e6

RepoURL extends from URL which has a default value of "". Because of this, it's impossible for repo_url to ever be None. At most it will be the empty string "".

This change modifies RepoURL to check for this empty string state instead of None, it also adds a test-case for a config with a edit_uri and empty repo_url.

After the change, the template works as expected:
Screen Shot 2019-10-02 at 4 51 32 PM

@@ -308,6 +308,7 @@ def post_validation(self, config, key_name):
# ensure a well-formed edit_uri
if edit_uri:
if not edit_uri.startswith(('?', '#')) \
and config['repo_url'] is not '' \
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change fixes the problem we experienced, I modified the above conditionals as well since they were unreachable before.

@waylan
Copy link
Member

waylan commented Oct 3, 2019

Note that edit_uri is specifically documented as being only a partial path. Your change causes the behavior to not agree with the documentation. As the current behavior was intentional, I'm inclined to not make the change.

Regardless of the above, how are you using edit_uri as a full URL? I understand the "edit on GitHub" link is not included. But where does edit_uri get used without repo_url?

@DiscoStarslayer
Copy link
Author

DiscoStarslayer commented Oct 3, 2019

Fair point! I think our current configuration may just be a misunderstanding of the documentation.

As for how we are using edit_url, we have 2 repos. xqemu/xqemu which hosts the main project, and xqemu/xqemu.com which hosts the mkdocs project that acts as our landing page and documentation for users + developers.

To make this config work we had repo_url as https://github.com/xqemu/xqemu/ and the edit_uri as https://github.com/xqemu/xqemu.com/blob/master/docs/. This way if a user clicks on "edit this page" they go to our xqemu.com project and if they click on the repo link in the top right of the page they go to the main xqemu project.

Seems like it was just dumb luck that this worked at all since it wasn't an intentional mkdocs feature haha.

Right now we are considering removing the link to the main project as we want the page to be more user focused, but it would be nice to keep the edit_url around for anyone to submit typo fixes or extra content.

While the defaults are nice if the docs share the same repo as the main project, our docs are more user specific and I feel like conceptually it's easier to manage it as a separate repository (can keep all documentation related PR's in one space separate from main project PR's for instance).

Given this isn't an intentional feature though, I think the better approach may be to just fork the theme we're using and customize it to follow our needs.

Unless you think this is a valid use-case you want to support, then I would be happy to help develop it with documentation + testing.

@waylan
Copy link
Member

waylan commented Oct 3, 2019

Ah, your documentation and code are in separate repos. I hadn't considered that scenario when reading your initial report.

Given this isn't an intentional feature though, I think the better approach may be to just fork the theme we're using and customize it to follow our needs.

That seems like a more reasonable approach to me. As you note, MkDocs expects the documentation to be in the same repo as the code. If you are doing something else, then you'll need to do some customization to make that work.

Note that instead of forking a theme, you may be able to address this with a plugin which modifies the settings after the builtin validation completes (via the on_config event). That might even make for a popular general-use third party plugin as I'm sure many users have (or would like to have) their code and documentation in separate repos. If there are any changes we need to make to MkDocs to make this easier (so long as the documented behavior is retained), please let us know.

@waylan
Copy link
Member

waylan commented Oct 3, 2019

Perhaps I should mention that we had tentatively planned to break the existing repo related feature out into a plugin which would be more feature complete and support more use cases. We just haven't gotten to it yet. If anyone is up for the work, I'm happy to provide guidance. If anyone is interested in developing and maintining it as a third party plugin, even better.

@DiscoStarslayer
Copy link
Author

Good call, and thank you for taking the time to respond and giving me some direction. I think the plugin approach is preferable for sure.

we had tentatively planned to break the existing repo related feature out into a plugin which would be more feature complete and support more use cases. We just haven't gotten to it yet.

Do you have a link to this discussion, or can point to a summary? I'd be interested in seeing what the other use cases may be outside of a split repo that isn't covered by the current config.

I think short term I will look at developing a 3rd party plugin to cover our use case, but I wouldn't be against trying to cover the other needs with the same plugin long term.

@waylan
Copy link
Member

waylan commented Oct 3, 2019

Do you have a link to this discussion, or can point to a summary?

See this comment for my proposed solution. although the entire discussion is relevant. The primary issue is that the current system doesn't work with all services or for all possible situations. By using a template based URL, any arrangement of URL parts could be defined by the user which is required for any situation a user might have.

@waylan waylan closed this Nov 26, 2019
@oprypin
Copy link
Contributor

oprypin commented Aug 13, 2022

It seems that #2733 happens to fix the issue that repo_url can just be equal to /. But now it remains empty and still blocks the ability to ever use edit_uri. I intend to fix that and I'll link a pull request to this soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants