1.0 Release?

[itdaniher]

After a few days and maybe dropping in docopt-ng for some popular projects that use docopt, I'm hoping to do a 1.0 release - slightly breaking semver, but with 100% coverage I think the project deserves to be pulled out of "beta".

[cjwelborn]

I'm gonna test it out on my projects this weekend. I use docopt heavily, and even modify it's behavior a little in my Colr library (optionally, to colorize docopt usage strings). I do this by importing docopt from Colr, where a couple functions/error-classes have been overridden. I'll have to modify Colr a little, to use docopt-ng when available. Not that any of this is your problem, just letting you know that I plan on putting docopt-ng to the test. I doubt there will be any bugs on your end, but if there are then I'll file an issue.

[itdaniher]

@cjwelborn that sounds wonderful, thanks for taking the initiative! Looking forward to hearing how the tests go.

Looking at Colr: assuming you don't intend to support the more_magic functionality of docopt-ng, no changes should be required. If you want more magic, ie

• long-argument spellcheck (--hel -> --help, --verBOse -> --verbose)
• the arguments variable to be populated in the globals namespace if docopt() isn't assigned
• __doc__ from the calling namespace to be used if docstring isn't passed to docopt(), and
• more_magic to be set to True if docopt() is aliased to a function name containing magic (from docopt import magic_docopt)

then a few changes will be required, but not many.

Cheers!

[cjwelborn]

@itdaniher, cool. Thanks for the extra info. I'll get back to you.

[cjwelborn]

I ended up having to upgrade my OS this weekend and ran into trouble. I haven't been able to do any real testing so far. Only thing I've noticed is that the variable type annotations kill support for anything less than Python 3.6. A 1.0 release may be mandatory since breaking changes were introduced. The only other option I can think of involves losing all of the type-checked goodness. I'm still going to test this out on my projects ASAP.

[cjwelborn]

Okay, so I've been testing this out with my stuff and it looks like it introduces major breaking changes. It's not a "drop-in" replacement for the old docopt. Parameter names have changed, so any program calling docopt like: docopt(usagestr, help=False) is going to fail. I would think a major version change is needed at the very least. Also, since both projects install as docopt (import docopt), you can't have both installed at the same time. I don't know how you would feel about renaming the module to docopt_ng or something simlar, but I'd at least do a 1.0 to mark these breaking changes.

[itdaniher]

Renaming to docopt_ng is probably reasonable. I'll also go through and make sure the parameter names for the keyword arguments match docopt, feel free to open a bug. Anything else blocking drop-in use?

[0x5c]

Any updates on this? I'm using docopt a lot, but it has tons of issues, and has been seemingly abandoned, so this fork seems like the solution moving forwards. Except that a seemingly ready release hasn't gone through which makes me doubt about the future of docopt-ng :/

[cjwelborn]

I'd still like to see a docopt_ng package also. I have so many scripts/tools using docopt right now and a package of my own that hooks into docopt, that if I installed this package as-is I would spend hours fixing everything. With a new name, I could install it side-by-side with docopt and slowly start adapting to the new way of doing things. Eventually I could drop the old docopt altogether.

I don't like asking people to rename their projects, but it would help me out a lot if this was imported as anything except docopt.

[itdaniher]

@cjwelborn @0x5c - I've been pretty offline this summer (personal growth, moving my household) - but I'm interested in picking up some of the open TODOs here. I'll review the PR from @0x5c and plan my attack to address the compatibility issues @cjwelborn called out. Regards!

[itdaniher]

I don't like asking people to rename their projects, but it would help me out a lot if this was imported as anything except docopt.

Happy to change this :)

[itdaniher]

Except that a seemingly ready release hasn't gone through which makes me doubt about the future of docopt-ng :/

Total test coverage, type hinting were my original objectives - and I'm pretty sure the code's on PyPi. I was pretty happy with where things were, but @cjwelborn found a few compatibility issues I was meaning to address before my life got unusually crazy for awhile. Skepticism is always reasonable, but given my return to "extremely online" - doubts are probably a little excessive. Thanks again for your PR, will review shortly!

[0x5c]

That is good news! I'll keep docopt-ng in my toolbox then.

However, I am not comfortable with receiving undue credits, and especially for making PRs, so let's redirect that in the right direction:
Thank you to the person who actually submitted a PR :D

I may have a look at contributing though.

[johnscillieri]

I'd love to see it as {docopt_ng, docoptng, docopt2, etc} as well, exactly for the reasons above. I have a ton of existing docopt code I'd love to port over if they were API compatible but if not, having side-by-side installs would be almost as good.

Any thoughts on what it would take to get to a new package name?