Package Details: mkdocs 1.3.1-1

Git Clone URL: (read-only, click to copy)
Package Base: mkdocs
Description: Project documentation with Markdown
Upstream URL:
Keywords: generator static website wiki
Licenses: BSD
Conflicts: python-mkdocs
Provides: mkdocs
Submitter: None
Maintainer: AlphaJack
Last Packager: AlphaJack
Votes: 27
Popularity: 1.06
First Submitted: 2015-06-11 18:21 (UTC)
Last Updated: 2022-07-19 14:29 (UTC)

Latest Comments

jiggak commented on 2021-08-17 20:09 (UTC)

Missing dependency on python-dateutil

AlphaJack commented on 2021-06-30 23:35 (UTC)

@ainola I have just submitted the merge requests

ainola commented on 2021-06-18 16:17 (UTC)

The wiki on AUR submission guidelines [1] mentions using replaces(). In general, though, AUR users are expected to keep up with their packages as they're external to the repositories.

If you want me to mass move everything let me know when you're ready.


AlphaJack commented on 2021-06-17 09:11 (UTC)


Am I missing something?

Not really, in your opinion what would be the best way to perform this mass package renaming?
Perhaps adding "provides=(mkdocs-foo python-mkdocs-foo)" and "conflicts=(python-mkdocs-foo)" to the new "mkdocs-foo" package will make the transition painless and conflict-free for end users?

AlphaJack commented on 2021-06-15 18:44 (UTC)

Thanks, I have added it

wjhandley commented on 2021-06-15 10:49 (UTC)

This is currently missing a dependency on python-pyyaml-env-tag

ainola commented on 2021-06-11 22:32 (UTC)

Hi, AlphaJack:

The name "mkdocs" appears to be correct in accordance to the rules on naming Python packages [1]. As this is a standalone program and not a library closely related to the Python ecosystem, it sounds to me like it should remain as is and that python-mkdocs should instead be merged into this package. Indeed, looking through the "getting started" guide on mkdocs' website suggests that the only interaction with mkdocs is as a utility, much like Hugo. Is this correct?

I see that there are many "modules" for mkdoc that have a python- prefix as well; I would also argue that they should simply be "mkdoc-foo" rather than "python-mkdoc-foo" as, again, there's no real relationship to the Python ecosystem.

Am I missing something?


alan1world commented on 2021-03-09 15:20 (UTC)

Sadly now my fix won't work. mkdocs has a requirement for nltk buried in it and the requirement is for <3.5. Arch is now on 3.5.3, meaning there are two prerequisites that cannot be met.

Is there a way a package can install into a venv virtual environment?

dcelasun commented on 2021-02-19 00:10 (UTC)

I could patch it here but it's better if they update it upstream.

alan1world commented on 2021-02-19 00:08 (UTC) (edited on 2021-02-19 00:09 (UTC) by alan1world)

Brief initial test indicates that the current version of mkdoc is compatible with lunr-0.5.9, it's just blocked by a rigid requirement.

Changing the requirements line in is sufficent.

Installed into a venv environment with mkdocs-1.1.2 and lunr-0.5.9:

'lunr[languages]==0.5.8' to 'lunr[languages]>=0.5.8'

AlphaJack commented on 2021-02-16 22:04 (UTC) (edited on 2021-02-17 09:33 (UTC) by AlphaJack)

A workaround is downgrading python-lunr:

git clone
git checkout 74a34b4f2c0520babc3c8b2ba72112c90cde1347
makepkg -si


dcelasun commented on 2021-01-29 11:20 (UTC)

python-lunr is now at 0.5.9 so we'll have to wait for an update to mkdocs I think.

hiddeco commented on 2021-01-29 11:04 (UTC)

Broken again, python-lunr is now expected to be 0.5.8:

  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 3226, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 3255, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 570, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 583, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python3.9/site-packages/pkg_resources/", line 772, in resolve
    raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'lunr[languages]==0.5.8' distribution was not found and is required by mkdocs

Dirk commented on 2020-07-20 05:43 (UTC)

Thanks, that fix did it. It works now!

dcelasun commented on 2020-07-18 21:32 (UTC)

@dsohler I pushed a fix for python-lunr. Please update that package and try again.

Dirk commented on 2020-07-18 21:28 (UTC)

After update to 1.1.2 I now get the following message when trying to run mkdocs

pkg_resources.DistributionNotFound: The 'regex' distribution was not found and is required by nltk

dcelasun commented on 2020-07-18 06:54 (UTC)

Updated to 1.1.2. There are two new dependencies, python-mdx-gh-links and python-lunr.

Universebenzene commented on 2020-07-18 06:07 (UTC)

python-markdown has updated to 3.2.2 now in the repo. This package should be ready to update

dcelasun commented on 2020-05-21 09:02 (UTC) (edited on 2020-05-21 09:02 (UTC) by dcelasun)

The latest version of mkdocs (1.1.2) depends on python-markdown>=3.2.1. Unfortunately, the Arch package is stuck in 3.1.1 since February. Until that changes, I can't update this package.

dcelasun commented on 2020-02-07 14:30 (UTC) (edited on 2020-07-19 07:31 (UTC) by dcelasun)

@antran looks like you've installed python-livereload (a dependency of mkdocs) outside the package manager (perhaps with pip?) and now it's conflicting. Removing it should fix the problem.

antran commented on 2020-02-07 14:28 (UTC)


I am trying to install mkdocs but I get this error

python-livereload: /usr/bin/livereload exists in filesystem Errors occurred, no packages were upgraded.

Does anyone know how to fix it? Thank you so much. Best,

dcelasun commented on 2018-08-04 22:53 (UTC)

python-tornado 5 is in [community-testing] for now, I've reverted mkdocs until it's released into [community].

ruuda commented on 2018-08-04 21:34 (UTC)

This package is currently broken:

pkg_resources.DistributionNotFound: The 'tornado>=5.0' distribution was not found and is required by mkdocs

The package still has a requirement "python-tornado>=4.1", but mkdocs 1.0 requires Tornado 5.

dcelasun commented on 2018-08-03 17:14 (UTC)

Updated to 1.0 which comes with several backwards incompatible changes.

dcelasun commented on 2018-07-23 17:58 (UTC)

Please don't mark as out of date for alpha/beta builds.

dcelasun commented on 2018-02-28 06:26 (UTC)

I've adopted the package and moved depends to the top level. It should now work correctly with all AUR helpers.

commented on 2017-12-02 20:44 (UTC)

@arafey Sorry for the delay, it's up to date now.

arafey commented on 2017-11-09 02:54 (UTC)

@carlwgeorge, I will maintain this package if you are no longer interested in doing so. Regards

dcelasun commented on 2017-09-28 11:25 (UTC)

@carlwgeorge: I have never once used or mentioned yaourt, so I'm not sure why you think that would help me. Anyway, I have no intention of discussing this further, so this is my last comment on this topic.

commented on 2017-09-27 23:35 (UTC)

@dcelasun I'm not looking bicker about yaourt flaws again, but I did want to share this link with you in case you wanted to subscribe to it.

commented on 2017-06-15 21:20 (UTC)

@dcelasun I totally agree you are having yaourt UX issues. You should report those to yaourt.

dcelasun commented on 2017-06-13 20:36 (UTC)

@carlwgeorge: Thanks, but I'm not looking for an AUR helper that seemingly fits a specification that only you are aware of. _Especially_ since you think the current behaviour of depends/makedepends is a bug (which, literally no one else [0] seem to think so) and your only "proof" is some unnamed TU who might or might not have told you something that is or isn't relevant. So thanks, I'll pass. [0] P.S: Sorry for the snark, but it really gets on my nerves when people dismiss UX concerns on religious arguments and appeals to purity.

commented on 2017-06-13 19:12 (UTC)

@dcelasun I found out that pacaur works fine to build this package. Like I said before, switch to an AUR helper that respects the specification.

commented on 2017-06-04 02:45 (UTC)

> warning: cannot resolve "python-livereload>=2.5.1", a dependency of "mkdocs" If you see this warning, then you are using an AUR helper that doesn't properly handle the depends array being in the package function. I suggest switching to a different AUR helper. For example, pacaur cleanly builds this PKGBUILD.

commented on 2017-06-04 02:42 (UTC)

@dcelasun "An array of packages that must be installed before the software can be run." "An array of packages that are only required to build the software." It's not my understanding, it's the literal definition. This definition is not unique to Arch, it's the same for packaging RPMs (my $dayjob) and Debian packages. I never filed a but because an Arch Trusted User was the one who told me about it. I can't find a bug report for it, but I'll ask that TU if it was ever filed or why it was never fixed, perhaps he can shed some light on the situation. I'm not changing the PKGBUILD, so you can stop wasting your time giving me attitude. Your time would be much better spent finding an AUR helper that works, or filing a bug with your current AUR helper. It seems the core problem is that your AUR helper isn't looking ahead to see that one of the depends is also an AUR package, and must be built first.

dcelasun commented on 2017-06-03 08:50 (UTC)

@carlwgeorge: > Those tools should respect the PKGBUILD specification. > but there is a bug in makepkg where top level depends are installed at build time. If you are convinced your understanding of the PKGBUILD spec is correct, despite what *everyone* else (including the devs) are doing, surely you have reported this "bug" and can share a link with us, right?

commented on 2017-06-03 07:43 (UTC)

@dcelasun > Since this is not a split package, I think depends() should be on the top level. Being a split package is not a prerequisite of putting the depends array in the package function. > all you are doing is causing unnecessary problems for certain AUR helpers I'm not responsible for bugs in AUR helpers. Those tools should respect the PKGBUILD specification. > with exactly zero gain. You are making a faulty assumption that there is no gain. There is a difference between build requirements and run time requirements. You might think that this is covered in a PKGBUILD by having separate makedepends and depends arrays, but there is a bug in makepkg where top level depends are installed at build time. Moving the depends array to the package function actually makes the depends work as intended. This is the more technically correct solution, and benefits anyone who builds packages on separate systems from where they install them. I know you are going to point out that for people using AUR helpers the build system is also the installation system, but frankly that is irrelevant. If an AUR helper is not correctly following the specification then you should use a different AUR helper. > Additionally, you are violating the PKGBUILD spec [0]: "All packages required to make the package are required to be specified in the global depends and makedepends arrays." No, I'm not. python-livereload is not required to build mkdocs.

dcelasun commented on 2017-05-31 10:32 (UTC) (edited on 2017-05-31 10:36 (UTC) by dcelasun)

@carlwgeorge: Since this is not a split package, I think depends() should be on the top level. I've read the comments below, but all you are doing is causing unnecessary problems for certain AUR helpers with exactly zero gain. Additionally, you are violating the PKGBUILD spec [0]: "All packages required to make the package are required to be specified in the global depends and makedepends arrays." [0]

madnight commented on 2017-05-25 19:25 (UTC) (edited on 2017-05-25 19:28 (UTC) by madnight)

same issue as welkie over here and same solution i think that yaourt cannot resolve packages deps that are not in the offical arch repos and only available via aur, like python-livereload

commented on 2017-04-12 17:46 (UTC)

Both python-livereload and mkdocs build with makepkg and install with pacman. Anything outside of that is outside of my control. I suggest you report the issue to yaourt. It wouldn't be the first time that tool caused unnecessary build problems.

welkie commented on 2017-04-11 23:01 (UTC) (edited on 2017-04-11 23:04 (UTC) by welkie)

I continue to have the problem. I try to use yaourt to install mkdocs and I get: warning: cannot resolve "python-livereload>=2.5.1", a dependency of "mkdocs" I ended up having to override the default behaviour of Arch Linux and use pip to manage the packages. I added the directory where pip package binaries go when installed with "--user" ($HOME/.local/bin) and I installed mkdocs with "pip install --user mkdocs". I did manually change my mirrors to include only those in the US and Canada with that mirror list generator tool. Do you think that may be related? ______ UPDATE: I was able to use yaourt to install mkdocs. I first manually installed python-livereload and that succeeded. Then I used "yaourt -S mkdocs" and it succeeded finally. I have no idea why it wasn't able to automatically install the python-livereload dependency.

commented on 2017-04-10 21:24 (UTC)

That is another AUR package, and it is currently at 2.5.1-1, which satisfies the dependency. I'm not sure what issue you are having, but I can install mkdocs with no issue.

welkie commented on 2017-04-10 20:35 (UTC)

I'm getting the following message when I try to install mkdocs: warning: cannot resolve "python-livereload>=2.5.1", a dependency of "mkdocs" :: The following package cannot be upgraded due to unresolvable dependencies: mkdocs

XavierCLL commented on 2016-04-30 05:08 (UTC) (edited on 2016-04-30 05:29 (UTC) by XavierCLL)

Hi, the themes bootstrap and bootswatch should not be dependences, change it to optdepends

davidmcinnis commented on 2016-02-10 04:03 (UTC)

Got it. Thanks! -Dave

commented on 2016-02-05 20:30 (UTC)

@davidmcinnis Could you please read the comment immediately before yours?

commented on 2016-01-09 16:38 (UTC)

@daurnimator Putting the depends in the package function is explicitly allowed by the PKGBUILD specification [1]. As such, it works just fine with makepkg and makechrootpkg. If your aur helper tool isn't respecting the PKGBUILD specification, you should file a bug with them. [1]:

daurnimator commented on 2016-01-08 02:57 (UTC)

`depends` should be at the top level; otherwise aur-helpers fail.

commented on 2015-07-11 03:23 (UTC)

@kmacleod It isn't in the upstream sources; I generated it myself. Because mkdocs uses click, it was easy to do. I used those instructions to generate a completion file and I uploaded it to the AUR with the PKGBUILD. Cloning this package or downloading a snapshot both include the file. What is the problem you are seeing?

kmacleod commented on 2015-07-10 20:59 (UTC)

mkdocs.bash_completion isn't availabe in the sources.