octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add doctest pkg to octave-forge


From: Carnë Draug
Subject: Re: Add doctest pkg to octave-forge
Date: Wed, 8 Jul 2015 21:45:08 +0100

On 8 July 2015 at 11:45, Colin Macdonald <address@hidden> wrote:
> On 08/07/15 06:43, Oliver Heimlich wrote:
>> [...]
>> However, there are also disadvantages: The current developers of doctest
>> (Michael and Colin) do not have access to the Core repository. The patch
>> tracker is a very slow mechanism for “outsiders”. Development would probably
>> take place in a clone of the Octave repository. Better ideas? Commit access?

I think bitbucket is the main gratis host for mercurial.  I do not know of
one that is free though.  Indeed, pulling csets from a clone hosted somewhere
else is a much nicer alternative than uploading patch files.

About giving you push access to octave, that's jwe and Jordi's decision.

>>
>> Also Octave Forge developers might not want to switch to the 4.2 branch
>> yet. They could not use doctest until the release?!? No! The current
>> doctest package from Github should already contain enough functionality
>> for most—if not all—packages and could be used until then. At some point
>> Forge developers will switch to 4.2 and the package is no longer needed.
>
>
> So in the meantime, let's make it OF package so those developers can simply
> "pkg install -forge doctest" to get it?

Done then

  https://sourceforge.net/p/octave/doctest/ref/master/

> That way if Michael and I drop or give up on the merge effect, then at least
> we have the OF package.  (And when its merged to core, we drop the OF
> package.)
>
> So far I agree with Oliver and Carnë's comments about a merge to core being
> desirable.  A few concerns with merge with test():
>
> 1. Minor point but Python keeps seperate test/doctest commands.

Python has namespaces which allows for a better organization.  They can
have all options of a function of ours as a separate functions in a namespace
and it will still look nice.  We don't have that luxury :(

> 2. Perhaps some developers will resent the workload of having
>    examples that must pass doctests.  So test() will probably
>    need a flag to disable doctests.  If this ended up being
>    *by default* then I'm not convinced a merge is worth the
>    effort.

Agreed.  So we have the default to be run the doctest as well.

Carnë



reply via email to

[Prev in Thread] Current Thread [Next in Thread]