EPEL7

[carlwgeorge]

Currently setup.py specifies that click must be at least version 4.0. I'm currently working with the Fedora package maintainer to get this added to EPEL for RHEL7. There are few dependency problems we are noticing.

• tornado>=4.1 and livereload>=2.3.2

In RHEL7 tornado is stuck at 2.2.1. livereload isn't packaged for RHEL7 at all (yet). As far as I can tell, these are only needed for the serve subcommand. Would you consider changing these requirements to extras?

extras_require = {
    'serve subcommand':  [
        'livereload>=2.3.2',
        'tornado>=4.1'
    ]
}

• click>=4.0

As a test, I manually edited the requires.txt in my egg-info directory after installing, and mkdocs appears to work just fine with click 3.3. Are there any known or planned features that actually require click 4.0?

[d0ugal]

Are there any known or planned features that actually require click 4.0?

Good question. I think 4.0 was just the most recent version when I wrote the CLI interface and I didn't test against older versions.

Would you consider changing these requirements to extras?

I don't really want the serve command to require extra install steps. I wasn't aware that rpms would use the setup.py at all, is there a way you can skip those requirements during packaging?

[waylan]

As I recall, any earlier versions of livereload will break MkDocs on some platforms (see #518 for example) and the 2.3.2 version of livereload requires at least version 4.1 of Tornado.

[carlwgeorge]

I don't really want the serve command to require extra install steps.

That is understandable.

I wasn't aware that rpms would use the setup.py at all, is there a way you can skip those requirements during packaging?

The RPM build process calls python setup.py build and python setup.py install. I believe the first command creates the requires.txt file in a mkdocs*.egg-info directory. It is possible to account for the problems in the RPM by patching the setup.py file before building, which is probably what @williamjmorenor (Fedora maintainer) is going to do.

I think 4.0 was just the most recent version when I wrote the CLI interface and I didn't test against older versions.

Can you take a peek at the 4.0 changelog and see if any of those changes sound critical to mkdocs? If not, lowering the minimum version in setup.py would be very appreciated, since it will be one less thing to patch in the RPM build.

[williamjmorenor]

Well in the epel7 packaging I am droping the missing requieres in the setup.py file (look at lines 53 and 54) so I can drop the click depency so pkg_reources do not fail if there is not the explicit version available.

http://pkgs.fedoraproject.org/cgit/mkdocs.git/tree/mkdocs.spec?h=epel7

Anyway the new and build comands should work fine and I understand than there is no a --no-liveread option to pase to the serve comando should mkdocs can be fully funtional in epel7 after that.

[carlwgeorge]

@williamjmorenor A patch for setup.py would be safer than sed'ing out specific lines, as those line numbers may change in future releases. I can add the patch if you would like to add me as a co-maintainer, FAS username is "carlgeorge".

[williamjmorenor]

This build do not requieres is specific tornado, livereload and click versions

https://koji.fedoraproject.org/koji/buildinfo?buildID=701080

[d0ugal]

It looks like this was resolved. I don't think we needed to do anything in the end.

[carlwgeorge]

@d0ugal Would it be possible to lower the minimum version of click to version 3.3? Here are the features added between 3.3 (current EPEL7 version) and 4.0 (your specified minimum version).

- Added `color` parameters to lots of interfaces that directly or indirectly
  call into echoing.  This previously was always autodetection (with the
  exception of the `echo_via_pager` function).  Now you can forcefully
  enable or disable it, overriding the auto detection of Click.
- Added an `UNPROCESSED` type which does not perform any type changes which
  simplifies text handling on 2.x / 3.x in some special advanced usecases.
- Added `NoSuchOption` and `BadOptionUsage` exceptions for more generic
  handling of errors.
- Added support for handling of unprocessed options which can be useful in
  situations where arguments are forwarded to underlying tools.
- Added `max_content_width` parameter to the context which can be used to
  change the maximum width of help output.  By default Click will not format
  content for more than 80 characters width.
- Added support for writing prompts to stderr.
- Fix a bug when showing the default for multiple arguments.
- Added support for custom subclasses to `option` and `argument`.
- Fix bug in ``clear()`` on Windows when colorama is installed.
- Reject ``nargs=-1`` for options properly.  Options cannot be variadic.
- Fixed an issue with bash completion not working properly for commands with
  non ASCII characters or dashes.
- Added a way to manually update the progressbar.
- Changed the formatting of missing arguments.  Previously the internal
  argument name was shown in error messages, now the metavar is shown if
  passed.  In case an automated metavar is selected, it's stripped of
  extra formatting first.

If none of these are essential, there shouldn't be an issue lowering the minimum version requirement of click.

[waylan]

Would it be possible to lower the minimum version of click to version 3.3?

I did a quick review (a couple minutes) of the list of features added and nothing jumped out at me as a problem. But the only way to be sure is to test it. As a start, you could change the required version (also here) on a local copy and run the tests (with tox - see the docs). However, the tests of the click commands use mock objects for some stuff, so some manual testing would be necessary as well.

[carlwgeorge]

Thanks!