Discuss development strategy

[wapcaplet]

This issue is a quick-and-dirty way for developers who are interested in improving doctest to discuss a plan of attack, at least until we have a more permanent home. I hope Ian doesn't mind--if he does, he can tell us to get out of his back yard and we'll reconvene somewhere else :-)

So far I have attempted to tackle a couple of issues in my fork of doctest2:

• 13: Better than - A single period is now interpreted as a blankline, unless DONT_ACCEPT_BLANKLINE is turned on

• 14: More detailed wildcards besides ... - An alternative ellipsis marker <...> can now be used, without requiring you to turn on the ELLIPSIS directive

I've tested these with the cpython Mercurial repository and the changes appear to be backward-compatible. Lots more could be done; here are some open questions:

• How to host the doctest2 project? I don't want to continue squatting in Ian's repository; I could start a new github repository and manage this effort if necessary. We'll at least need somewhere to discuss things--maybe an IRC channel or mailing list.
• How to distribute it? Paul Brian suggested treating it as a pip-installable patch to the regular Python doctest package. I think this makes good sense; a standalone distribution might reach a wider audience of testers (and developers), allowing doctest2 to be iterated and improved before it's submitted to the official Python dev team for consideration as part of the official doctest.
• How to get it into the official Python repo? I have never contributed to Python before; I've been reading through the developer's guide, but am not sure how well a large core-package enhancement like this might be received, in contrast to smaller patches or bugfixes. Are there procedures to follow that we should know about? Should we submit something to the [http://bugs.python.org/](issue tracker) before embarking on this journey?

Thoughts / suggestions? I want to make doctest more awesome and I would be happy to work with anyone else who shares this goal.

[lifeisstillgood]

Following the discussion on email:

Forking this into a new repo is the most natural way

I think an install process that politely patches doctest and provides very guaranteed back outs is a good idea. I suspect the best optin is two load package doctest_ng and a .pth that points to one or the other.

Not sure on the last point either but a mail to Tim peters probably can't hurt?

[wapcaplet]

Ian agreed to transfer ownership of this repository to me, so I can handle issue resolution, merging pull requests, adding collaborators and so on. This neatly resolves my first open question. @lifeisstillgood, if you would like to be a collaborator, please let me know.

About question 2, the use of a .pth file sounds a good idea. It would be ideal if someone could install doctest2 with a pip install doctest2 or pip install doctest_ng, then enable it (slot it in place of the standard doctest module) with a .pth file in the current directory. I'll play around with this a bit.

[lifeisstillgood]

I have had second thoughts on this one (not an egg fan) and to be fair until dockets_ng gets some momentum and is trusted, doing things like fiddling automatically with people's .pth is fairly presumptuous and likely to reduce our number of early adopters (besides our mothers)

So I suggest we just keep a set of patches against the arc of doctest and the resultant output is called doctest2 or ng and everyone does from doctest 2 import testmod

Early adopters can cleanly and easily see what's going on, no fear of backward compatibility problems across your whole codebase, the new hotness will only work where you explicitly tell it - perfect for people to try it out in real world situations, and as we promise to keep things simple, there is v little need for worrying about investing in new doc situation

I would suggest we tackle a couple of the usuals (output checker etc) and look at supplying it as an option in sphinx - which seems to be the place most do tests are written these days

Anyway thanks for picking up the ball and running with it - do add me as need to whatever kist and we shall see where we go

Cheers

[lifeisstillgood]

@wapcaplet - I expect to have some time next week to make a branch to allow all porcelain to set their own OutputChecker - it mostly works locally. how does this tie into your plans? PS sorry for adding comment - cannot find yr email (well any more easily than finding github)

[wapcaplet]

@lifeisstillgood: Sounds good. I have been caught up in other projects lately and haven't done anything with doctest2, so your contributions will be most welcome.

[kmike]

As for getting doctest_ng into Python: does this conflict with Python 2.x compatibility?

[lifeisstillgood]

I believe there is a number of do test changes already in 3. So we would probably have to fix for 2.7 (exists but needs proper integration) and then find same issues in 3

Paul Brian 07540 456 115 paul@mikadosoftware.com Guiding you towards Continuous Delivery of software and business value.

On 3 Mar 2013, at 10:21, Mikhail Korobov notifications@github.com wrote:

As for getting doctest_ng into Python: does this conflict with Python 2.x compatibility?

— Reply to this email directly or view it on GitHubhttps://github.com/wapcaplet/doctest2/issues/22#issuecomment-14344748 .

www.mikadosoftware.com

See your software improve with every change.