Extract autoreload facility into separate library about aiohttp-devtools HOT 16 CLOSED

It would be possible but I don't really see the point. What's stopping people from using aiohttp-devtools for just runserver? None of the other functionality should get in the way.

from aiohttp-devtools.

Regarding reload/runserver, perhaps I have a compromise that everyone can work with:

watchdog is old and crusty and buggy, I want to rebuild it with python 3.6 and proper support for asyncio. If that works it should obviously be a different package. It would have an interface as simple as (I'm guessing):

from watcher import Watcher

async def main():
    async for event in Watcher('/path/to/dir', filter='*.py', debounce=0.1):
        <do stuff when events occur>

Advantages:

• aiohttp-devtools would remain in one place, would get simpler and hopefully #118 would be fixed
• those who don't want to use aiohttp-devtools could get their code reloading on files changes very easily. But most people who just want an out-of-the-box way to run their aiohttp app in development wouldn't need to change anything or make a choice about which package to use.
• the package would have no dependency on aiohttp so would be more widely useful.

We could also remove jinja2 (which is required by the start command only) as a required dependency of aiohttp-devtools and allow people to install it with aiohttp-devtools[start]. That should please people who don't want to install an extra package for a subcommand they never use.

@sky-code @asvetlov does that satisfy?

from aiohttp-devtools.

I know what you mean, but we could add a very obviously

jinja2 is not installed, you will need to run 
> pip install aiohttp-devtools[start]
to fix this

which would explain it for 99% of people.

But you're right, I'll leave that until someone complains.

from aiohttp-devtools.

ok, I get where you're coming from, also I'm thinking about building (yet another) static site builder and will want to user the livereload.js integration, file watching and static file server form devtools for that which will require a separate package.

However a bigger problem is that watchdog has some problems when integrated with asyncio, see #118.

I think as well as separating the package the new package should integrate with inotify directly and provide a fallback to poll the fs.

The other question is, what should be moved to a new package:

• filesystem watch/notify? yes
• static file server using aiohttp with livereload.js integration? yes
• "runserver" aiohttp app reloading and serving? I guess so

In that situation devtools would become just a meta-package (as you suggested) for aio-reload as well as implementing the start cookiecutter command.

from aiohttp-devtools.

Hmm, you are right.
Maybe you could point the feature on very start of docs?

IIRC people said "we don't need all aiohttp-devtools features but only autoreload one.
If README will point on this use case everybody will be happy.

P.S.
Personally I don't want to reimplement it in aiohttp or create and support yet another library.
Maybe it is just documentation problem?

from aiohttp-devtools.

+1 for separate package.
Why aiohttp-debugtoolbar is separate package, but autoreload not?
What if i need to install autoreload without aiohttp-debugtoolbar and cli tools from aiohttp-devtools?

Move auto-reload to separate package, same as aiohttp-debugtoolbar then aiohttp-devtools will become a meta package for all dev-tools and cli utilities like adev start

from aiohttp-devtools.

Why aiohttp-debugtoolbar is separate package, but autoreload not?

Because it was started before aiohttp-devtools. Simple as that.

Please explain practically why you can't use aiohttp-devtools for just its runserver functionality?

My suspicion is that people don't like the idea of using devtools because it includes start which they think is for newbies, if that's the case it's irrational and not a good reason to split a package.

If someone can explain practically why a separate aiohttp-reload or aiohttp-runserver would be more usable I'll work on splitting the package.

By the way, before building aiohttp-devtools I built https://github.com/samuelcolvin/aiohttp_runserver, and people said

it would be a huge turn off for me if all of the debug and development tools are scattered around a bunch of small external repositories that may never get maintained.

That makes a lot of sense to me particularly for new developers, it's a better argument than any I've heard to go the other way and split packages. It's also the feeling I got when dabbling with flask.

on the subject of debugtoolbar: As far as I can tell debugtoolbar is attempting to do too much for the time/effort available from contributors; a lot of it's javascript is rusty and unmaintained/untrusted/un-owned. Also as aiohttp doesn't have a default database backend the most useful features of a debug toolbar like query log and counts can't be provided. Same goes for template render and showing template context.

from aiohttp-devtools.

Please explain practically why you can't use aiohttp-devtools for just its runserver functionality?

For me it's documentation, no example of usage live-reload by api in python code (only cli).

If someone can explain practically why a separate aiohttp-reload or aiohttp-runserver would be more usable I'll work on splitting the package.

It's all about separation of concerns, you can pull all in one lib or separate then by features.

In my opinion separate autoreload feature in another package will clarify things, but in general i agree with @asvetlov - main problem is a missing of detailed documentation. Can you please add docs for usage autoreload from python code? Same as here: https://github.com/and800/aioreloader
Also will be good to restructure docs into block for api and for cli

from aiohttp-devtools.

I think there is an agreement that auto reload API must be documented, instead of forking the code into a separate package and repository which is a pain to maintain.

from aiohttp-devtools.

My suspicion is that people don't like the idea of using devtools because it includes start which they think is for newbies, if that's the case it's irrational and not a good reason to split a package.

Exactly my feeling.

Maybe making a dozen of aiohttp debug libraries and providing meta aiohttp-devtools is good idea but it requires a lot of work. Honestly I just have not time for it (and pretty sure @samuelcolvin has not too).

Regarding to aiohttp-debugtoolbar. Unfortunately the library is not at first place in my personal todo list.
@jettify is overwhelmed too, he has much less spare time to work on Open Source than me unfortunately. We need more contributors.
@samuelcolvin if you do want to share the library ownership -- you are welcome.
Help from others is very appreciated too.

from aiohttp-devtools.

personally I don't use debugtoolbar at the moment, and even when I'm working on django projects I very rarely enable its (much more mature) debugtoolbar. I don't really want to take ownership of projects I don't use as I won't maintain them well.

from aiohttp-devtools.

Yes, in my opinion this is the best solution for the current situation.

from aiohttp-devtools.

+1 but I suggest keeping jinja2 dependency until explicit request by new issue.
Otherwise you'll get into constant questions: why adev start command doesn't work after installing the package?

from aiohttp-devtools.

The decision is up to you.

from aiohttp-devtools.

+1 for proposed message when jinja2 is not installed.
These changes obviously require new major version and can be backward incompatible.

from aiohttp-devtools.

Ok, this is now solved properly.

If you desire nothing more than the reload functionality I recommend you use watchgod which in turn is used by aiohttp-devtools for the reload funcitonality.

As per the docs here you can run code and reload it on changes with watchgod foobar.main.

Note: this is only preferable for those desiring absolute minimalism aiohttp-devtools does lots of clever things you don't get with watchgod like livereload, coloured request logging, static file serving.

from aiohttp-devtools.