Repository: mkdocs/mkdocs

Issue:
AttributeError: 'module' object has no attribute 'TornadoAsyncNotifier'
Using Python 2.6.6 on CentOS, I'm unable to run the server with livereload:

```
[mkdocs@dev test-docs]$ python /home/mkdocs/.local/lib/python2.6/site-packages/mkdocs/__main__.py serve --dev-addr=0.0.0.0:8080
WARNING: Support for Python 2.6 will be dropped in the 1.0.0 release of MkDocs

INFO    -  Building documentation... 
INFO    -  Cleaning site directory 
[I 161205 22:16:26 server:283] Serving on http://0.0.0.0:8080
[I 161205 22:16:26 handlers:60] Start watching changes
Traceback (most recent call last):
  File "/home/mkdocs/.local/lib/python2.6/site-packages/mkdocs/__main__.py", line 227, in <module>
    cli()
  File "/home/mkdocs/.local/lib/python2.6/site-packages/click/core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "/home/mkdocs/.local/lib/python2.6/site-packages/click/core.py", line 696, in main
    rv = self.invoke(ctx)
  File "/home/mkdocs/.local/lib/python2.6/site-packages/click/core.py", line 1060, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/mkdocs/.local/lib/python2.6/site-packages/click/core.py", line 889, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/mkdocs/.local/lib/python2.6/site-packages/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/home/mkdocs/.local/lib/python2.6/site-packages/mkdocs/__main__.py", line 127, in serve_command
    livereload=livereload
  File "/home/mkdocs/.local/lib/python2.6/site-packages/mkdocs/commands/serve.py", line 88, in serve
    _livereload(host, port, config, builder, tempdir)
  File "/home/mkdocs/.local/lib/python2.6/site-packages/mkdocs/commands/serve.py", line 27, in _livereload
    server.serve(root=site_dir, host=host, port=int(port), restart_delay=0)
  File "/home/mkdocs/.local/lib/python2.6/site-packages/livereload/server.py", line 300, in serve
    LiveReloadHandler.start_tasks()
  File "/home/mkdocs/.local/lib/python2.6/site-packages/livereload/handlers.py", line 61, in start_tasks
    if not cls.watcher.start(cls.poll_tasks):
  File "/home/mkdocs/.local/lib/python2.6/site-packages/livereload/watcher.py", line 160, in start
    self.notifier = pyinotify.TornadoAsyncNotifier(
AttributeError: 'module' object has no attribute 'TornadoAsyncNotifier'
```

I can workaround by using `--no-livereload`, but is there a way to get livereload working?


Discussion:
Which versions of `livereload` and `tornado` do you have?

Perhaps you can try updating them to the latest versions:

    pip install -U tornado livereload

I have livereload 2.5.0 and tornado 4.4.2, both installed locally for my user. `pip install -U` tells me both are up-to-date.
I can't reproduce this locally. I wonder if this is a Python 2.6 incompatibility. I don't have that installed locally so I can't test this myself and our automated tests aren't having any problem, although they don't necessarily test the third party libs we use.

As a test, let's see if livereload is working on its own by manually building the site and using livereload directly. Try the following commands:

```bash
mkdocs build
cd site
livereload
```

If that raises the same error, then the problem is upstream. If not, then we have a problem with MkDocs use of livereload.

As an aside, using livereload like that won't work the same as using our wrapper. You would still need to `build` manually every time. With our wrapper, the builds are automated too.
I think either livereload or tornado (or both?) dropped support for Python 2.6 some time ago. I think we also did, but I'm not sure if we broke anything in the process.






On Wed, Dec 7, 2016 at 2:50 AM +0000, "Waylan Limberg" <notifications@github.com> wrote:












I can;t reproduce this locally. I wonder if this is a Python 2.6 incompatibility. I don't have that installed locally so I can't test this myself and our automated tests aren't having any problem, although they don't necessarily test the third party libs we use.


As a test, let's see if livereload is working on its own by manually building the site and using livereload directly. Try the following commands:
mkdocs build
cd site
livereload


If that raises the same error, then the problem is upstream. If not, then we can a problem with MkDocs use of livereload.


As an aside, using livereload like that won't work the same as using our wrapper. You would still need to build manually every time. With our wrapper, the builds are automated too.



—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


  
  










I tried quickly on Python2.6 and nothing works for me. python-markdown uses
importlib which isn't installed. Installing the backport gets you slightly
further, but we use OrderedDict from collections - so that fails too. There
isn't a simple backport for this, as we import it from collections. If we
used the OrderedDict package that would solve it. I didn't investigate any
further.

I think we need to remove this warning and change it to an error now:
https://github.com/mkdocs/mkdocs/blob/master/mkdocs/__init__.py#L8-L10 and
also remove 2.6 from the setup.py

On 7 December 2016 at 08:44, Dougal Matthews <dougal@dougalmatthews.com>
wrote:

> I think either livereload or tornado (or both?) dropped support for Python
> 2.6 some time ago. I think we also did, but I'm not sure if we broke
> anything in the process.
>
>
>
>
>
> On Wed, Dec 7, 2016 at 2:50 AM +0000, "Waylan Limberg" <
> notifications@github.com> wrote:
>
> I can;t reproduce this locally. I wonder if this is a Python 2.6
>> incompatibility. I don't have that installed locally so I can't test this
>> myself and our automated tests aren't having any problem, although they
>> don't necessarily test the third party libs we use.
>>
>> As a test, let's see if livereload is working on its own by manually
>> building the site and using livereload directly. Try the following commands:
>>
>> mkdocs buildcd site
>> livereload
>>
>> If that raises the same error, then the problem is upstream. If not, then
>> we can a problem with MkDocs use of livereload.
>>
>> As an aside, using livereload like that won't work the same as using our
>> wrapper. You would still need to build manually every time. With our
>> wrapper, the builds are automated too.
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to this email directly, view it on GitHub
>> <https://github.com/mkdocs/mkdocs/issues/1106#issuecomment-265340547>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AAC8U-_Sb3E6bDn9M7HxwNa6QzjT7_-uks5rFh7jgaJpZM4LFEXQ>
>> .
>>
>

Travis is still running the PY2.6 tests so I assumed it still works. I realize Python-Markdown dropped support some time ago but I assumed MkDocs still worked with an older version. Perhaps the few untested areas are the problem. 

In fact I ran into a few problems with 2.6 tests failing (which I was able to resolve) when trying to get 0.16 out the door. I'm happy to see it go. Just didn't think we were there yet. 
That is a good point, I forgot Travis covered this - maybe I done something wrong with my test. I'll try again tomorrow.

The plan was to drop it for 1.0 anyway, so we can do that soon. Seems 0.16 is pretty solid - maybe we just do a quick release with the couple of bug fixes and then start the cleanup?
> The plan was to drop it for 1.0 anyway, so we can do that soon. Seems 0.16 is pretty solid - maybe we just do a quick release with the couple of bug fixes and then start the cleanup?

That was my thinking as well.
I am hitting this... is there an easy fix?

I'm on Python 2.7.3 (default, Jun 22 2015, 19:33:41) 
[GCC 4.6.3] on linux2

and if it helps I tried 
```
mkdocs build
cd /home/erich/civicrm-dev-docs/site 
livereload 
```

and got a similar error:

```
[I 170106 22:02:35 server:283] Serving on http://127.0.0.1:35729
[I 170106 22:02:35 handlers:60] Start watching changes
Traceback (most recent call last):
  File "/usr/local/bin/livereload", line 9, in <module>
    load_entry_point('livereload==2.5.0', 'console_scripts', 'livereload')()
  File "/usr/local/lib/python2.7/dist-packages/livereload/cli.py", line 39, in 
main
    server.serve(host=args.host, port=args.port, root=args.directory)
  File "/usr/local/lib/python2.7/dist-packages/livereload/server.py", line 300,
 in serve
    LiveReloadHandler.start_tasks()
  File "/usr/local/lib/python2.7/dist-packages/livereload/handlers.py", line 61
, in start_tasks
    if not cls.watcher.start(cls.poll_tasks):
  File "/usr/local/lib/python2.7/dist-packages/livereload/watcher.py", line 160
, in start
    self.notifier = pyinotify.TornadoAsyncNotifier(
AttributeError: 'module' object has no attribute 'TornadoAsyncNotifier'
```
related issue: https://github.com/clonn/simple-livereload/issues/1
ok so I've fixed this on my machine with

      sudo pip install pyinotify --upgrade

(was on `pyinotify==0.9.2` not on `pyinotify==0.9.6`)

> related issue: clonn/simple-livereload#1

Hmm, interesting as that is the Node/JavaScript livereload lib. Regardless, thanks for the workaround (upgrading pyinotify) @ErichBSchulz. Turns out that [lepture/python-livereload][0] requires at least `pyinotify=>0.9.4`.

In an effort to track this down, I noticed that pyinotify is not listed as a dependency of either [lepture/python-livereload][0] or its dependencies. In fact, it isn't even installed on my virtualenvs (I checked with `pip freeze`). But, with a little digging, I see that the import [fails gracefully][1] and a [different code-path][2] is followed when the lib is not installed. 

[pyinotify][3] is a Linux-specific lib and not available on other platforms (thus python-livereload's graceful fallback). In fact, I haven't noticed any issues with it not being installed on my local Linux system. That said, it is a wrapper around the [inotify][4] lib and is likely much more performant than the home-grown system for other platforms. We can't expect users to not have it installed, and there is no reasonable way to force users who do to upgrade (if needed) when python-livereload is installed. 

Regardless, this should be an upstream issue for python-livereload. lepture/python-livereload#143 already raises the issue that pyinotify support is not documented. I opened lepture/python-livereload#148 to add a check for the pyinotify version and fallback gracefully if an older version is installed.

Once that (or a similar fix) gets accepted and included in a new version of python-livereload, we can update our version requirement for that lib. Until then, we'll leave this open to remind us.

[0]: https://github.com/lepture/python-livereload/
[1]: https://github.com/lepture/python-livereload/blob/master/livereload/watcher.py#L15-L18
[2]: https://github.com/lepture/python-livereload/blob/master/livereload/watcher.py#L168-L171
[3]: https://pypi.python.org/pypi/pyinotify
[4]: http://man7.org/linux/man-pages/man7/inotify.7.html
@waylan A new version of livereload is released.
@lepture awesome! Thanks. 

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -60,7 +60,7 @@ def get_packages(package):
     install_requires=[
         'click>=3.3',
         'Jinja2>=2.7.1',
-        'livereload>=2.3.2',
+        'livereload>=2.5.1',
         'Markdown>=2.3.1,<2.5' if PY26 else 'Markdown>=2.3.1',
         'PyYAML>=3.10',
         'tornado>=4.1',


Test patch: