Integrate docopt-dispatch in this project

[bittner]

I have started using docopt-dispatch and I find it very intriguing. It makes docopt CLI code super-concise and readable.

Unfortunately, that package both has docopt as a hard dependency and is unmaintained for 7+ years.

If we integrated the dispatching project in docopt-ng some CLI code could look like this, preserving the compatibility with the original docopt spec and staying aligned with the syntax of the original dispatch project:

"""Run something in development or production mode.

Usage: run.py --development <host> <port>
       run.py --production <host> <port>
       run.py remote add <item>
       run.py remote delete <item>
"""
from docopt import dispatch


@dispatch.on('--development')
def development(host, port, **kwargs):
    print('in *development* mode')


@dispatch.on('--production')
def development(host, port, **kwargs):
    print('in *production* mode')


if __name__ == 'main':
    dispatch(__doc__)

Would you accept a PR that adds the dispatching feature to docopt-ng?

[bittner]

@NickCrews Interested?

[bittner]

Any opinion on this, @NickCrews?

Let me know if there's a problem with the idea and if there's anything I can do about it. Thanks!

[NickCrews]

Hey @bittner, sorry this has taken me so long to respond to this.

It looks like the original docopt-dispatch worked fine as an extension to docopt, so couldn't you port that over? If it can remain an external project and not have to be integrated into the core, that would be much better.

[bittner]

It looks like the original docopt-dispatch worked fine as an extension to docopt, so couldn't you port that over?

What exactly do you intend to say? I should fork the project and upload a new one to PyPI?

(If it's that, no. I'm not planning on being the maintainer of yet another new package. I have enough projects running.)

If it can remain an external project and not have to be integrated into the core, that would be much better.

Do you believe this project is still in line with the original project? Will the user code be backwards-compatible? What's your point of retaining a "core"? What is the "core" anyway?

If we can't guarantee backwards-compatibility to a 100% shouldn't we let that idea of the "core" go? We could more pragmatically discuss the integration of new features and enhancements.

I agree that some sort of "compatibility" is helpful, mostly to help users to migrate from using docopt to docopt-ng, but if we're too dogmatic about that we'll end up with yet another dead horse project that needs to be forked.

[NickCrews]

I should fork the project and upload a new one to PyPI?

Yeah that's what I meant. Adding the code here doesn't make it less work, it just moves it around. If adding it here was less work than having it separate (which sometimes happens if it's necessary to access the internals) then I would be more willing to integrate, but since it so easily works as an extension.... IDK, do you disagree with that analysis?

Re original intent, idk if you saw release 0.9.0 that I just released, but in that I removed the "magic" stuff, in an attempt to re-distill this package back to its core. I was hemming and hawing over this, I almost didn't, but you can see my reasoning in the changelog. I'm genuinely curious, as an active user of docopt what do you think about this?

By core, I mean "function that takes a usage message and sys.argv, and returns a dict". Finding that usage message, and dispatching that dict, are separate tasks. I think that the parsing that docopt does is complex and worthy of being its own package. If it makes sense, I can expose some more internals so others can more easily build extensions, but so far that hasn't come up that I know of.

Are there other incompatibilities that you know of? I didn't think there were that many. Some things, if they don't increase scope too much, I'm willing to look into, such as #47.

I understand your fear of a dead horse. I admit I haven't done a ton of open source maintainership so I'm actively trying to find a balance here. Sorry as I figure this out. I'll open an issue where people can chime in in general so we can get a sense of the direction the community wants.