Re: general package, inputParser, 4.0.0 release

[Carnë Draug]

On 22 May 2015 at 20:11, Philip Nienhuis <address@hidden> wrote:
>
> I.e., merely the current general package with the only change being a new
> depends = Octave < 4.0.0.
> Looks easy, simple and effective.
>
> What about other packages depending on it?
> linear-algebra seems OK (depends Octave >= 4.0.0, although on octave.sf.net
> it still says Octave >= 3.8.0 & general > 1.3.0)

You made that release.  It claims to be dependent on whatever you said it
was.  Looking at it now, its usage of inputParser actually makes the package
dependent on Octave 4.0.0 and does not make use of the general package at
all.

> Any other packages depending on inputParser?

I don't think so.  As far as I know, all dependencies on the general package
are due to the inputParser.  I believe the only packages that made use of it
were image, signal, and linear-algebra, and it has been fixed on those
packages.  If not, since the two implementations of inputParser are
incompatible, it would be causing tests to fail.

On 22 May 2015 at 23:50, Mike Miller <address@hidden> wrote:
> On Fri, May 22, 2015 at 18:50:28 +0100, Carnë Draug wrote:
>> Yes, that is one of the alternatives.  When I found this problem the first
>> time I started by removing @inputParser from the package.  There is even one
>> in the release packages forum.  But because of the points above (and
>> considering the other thread where I suggest dropping the general package),
>> I think we would be better off reinstating the @inputParser and releasing it
>> with depends (octave < 4.0.0).
>
> Your original point about this being confusing is fair and wanting to
> clear things up for users by having one definition makes sense.
>
> I would like to keep the signal package as backwards-compatible as is
> reasonably feasible. It currently depends on octave >= 3.8.0 and general
> for inputParser, it will work with either definition of the class.
>
> Let's assume for now I don't want to change those dependencies.
>
> For this situation which alternative would be better? If a new general
> is released that depends on octave < 4, would users of signal be forced
> to download an older version of general? Would "pkg load signal" fail if
> the new general package is installed? Or would Octave simply not load
> the new general package and everything would still work?
>

Ideally, you could have signal depend on (octave > 4.0.0 | general < 1.3.0)
but that does not work yet.  So if you don't change any of the dependencies,
users would have to find an older version of general that installs on
Octave 4.0.

> If a new package is released without inputParser, then signal would
> still depend on it, needlessly, but it wouldn't provide inputParser, and
> everything would definitely still work fine.
>
> I'm unsure how the "octave < 4.0.0" case will work, so I prefer the
> release with inputParser removed because I am more certain it will do
> what I want.

So the effect for users of signal can be:

  1 - we release general depending on "octave > 4" -- if they are using
    octave 4.0, all is fine.  If they use octave 3.8, they will have to
    search for an old version of the general package.

  2 - we release general depending on "octave < 4" -- if they are using
    octave 4.0, they need to search for an old version of general.  If they
    are using octave 3.8, all is fine.

Either way, there will always be a group that will have to either change
octave version or search for an old version of the general package.  But
I guess if we need to choose, it makes sense to favour users of the latest
Octave release.

Anyway, on the specific case of the signal package, I just pushed a change
that drops the dependency on general [1].  If it can't find the classdef
implementation of inputParser, it handles input check with parseparams()
instead.

With this fix, there aren't package depending on general anymore, and signal
can be used by anyone without any issues.

Carnë

[1] http://hg.code.sf.net/p/octave/signal/rev/405d2525604d