Completion collision, best way to fix

Completion collision, best way to fix

[Baptiste Daroussin]

Hi,

I am working on a completion function for the freebsd new package
manager, actually it is working:
https://github.com/pkgng/pkgng/blob/master/scripts/zsh/_pkg

I want to add the completion function to the main zsh git but I face
the problems:
The right place for it would be Completion/BSD/Command, but if I put
it there it will hide the Completion/Solaris/Command/_pkg5 has they
both define #compdef pkg

Is there a nice way to deal with this situation?

Merging both functions into one and pushed into unix, and condition
the completion base on the OSTYPE?

or is there some kind of #compdef_only_on_solaris pkg
#compdef_only_on_freebsd pkg thing available ?

regards,
Bapt

Re: Completion collision, best way to fix

[Bart Schaefer]

On Sep 28, 11:33am, Baptiste Daroussin wrote:
}
} I want to add the completion function to the main zsh git but I face
} the problems:
} The right place for it would be Completion/BSD/Command, but if I put
} it there it will hide the Completion/Solaris/Command/_pkg5 has they
} both define #compdef pkg
} 
} Is there a nice way to deal with this situation?

Theoretically, you ignore it and put the completion in BSD/Command/.
It's not the only such conflict.

The reason there are separate directories BSD/ and Solaris/ and so on
is to permit the person doing the install on one of those systems to
include or omit only the appropriate subset of completions -- or to
permit the user to omit the irrelevant ones from $fpath, if the
installer configured with --enable-function-subdirs (the default).

In practice I'm not sure any of the distribution package maintainers 
actually take the step of removing the "irrelevant" functions from the
tree; maybe some change the default fpath in /etc/zshrc or the like.

Re: Completion collision, best way to fix

[Danek Duvall]

On Fri, Sep 28, 2012 at 07:59:36AM -0700, Bart Schaefer wrote:

> In practice I'm not sure any of the distribution package maintainers 
> actually take the step of removing the "irrelevant" functions from the
> tree; maybe some change the default fpath in /etc/zshrc or the like.

Given that I'm the zsh integrator for Solaris ...

Is there a way for the build process to put the "native" OS-specific
directory ahead of the rest?  If not, would a patch to do that be
appreciated?  I could take the easy way out and simply drop the BSD _pkg
from the Solaris zsh package, but it'd be nice not to have to.

Thanks,
Danek

Re: Completion collision, best way to fix

[Baptiste Daroussin]

2012/9/29 Danek Duvall <duvall@comfychair.org>:
> On Fri, Sep 28, 2012 at 07:59:36AM -0700, Bart Schaefer wrote:
>
>> In practice I'm not sure any of the distribution package maintainers
>> actually take the step of removing the "irrelevant" functions from the
>> tree; maybe some change the default fpath in /etc/zshrc or the like.
>
> Given that I'm the zsh integrator for Solaris ...
>
> Is there a way for the build process to put the "native" OS-specific
> directory ahead of the rest?  If not, would a patch to do that be
> appreciated?  I could take the easy way out and simply drop the BSD _pkg
> from the Solaris zsh package, but it'd be nice not to have to.
>
> Thanks,
> Danek

What we could do is to provide a Unix/_pkg
Which will do the #compdef pkg and call _pkg5 on Solaris and _pkgng on FreeBSD?

if you agree on that I'll do the work and send it to you for review

While you are here will you accept FreeBSD specific completion for
_zfs ? :D like the jail/unjail subcommand

regards,
Bapt

Re: Completion collision, best way to fix

[Danek Duvall]

On Sat, Sep 29, 2012 at 03:39:24AM +0200, Baptiste Daroussin wrote:

> What we could do is to provide a Unix/_pkg
> Which will do the #compdef pkg and call _pkg5 on Solaris and _pkgng on FreeBSD?

Works for me -- it's certainly a far simpler solution -- though I hardly
have the final say on that.  Phil's solution would work for me, too.

> While you are here will you accept FreeBSD specific completion for
> _zfs ? :D like the jail/unjail subcommand

Sure.  As long as the CLIs don't diverge too strongly, and the OS checks
don't complicate the script too badly, that works just fine for me.  That's
why either Bart or Peter asked that it be put in Unix rather than Solaris
in the first place.

Danek

Re: Completion collision, best way to fix

[Bart Schaefer]

On Sep 29,  3:39am, Baptiste Daroussin wrote:
}
} What we could do is to provide a Unix/_pkg
} Which will do the #compdef pkg and call _pkg5 on Solaris and _pkgng on
} FreeBSD?

If you're going to do that, the correct way is to use _pick_variant
(Completion/Base/Utility/_pick_variant) to decide which flavor of "pkg"
you have.  That way people can use zstyle to control the choice.

} While you are here will you accept FreeBSD specific completion for
} _zfs ? :D like the jail/unjail subcommand

Have to wait for PWS to chime in, but generally speaking you can just
send it to zsh-workers for review ... of all the reasons it might be
rejected, being FreeBSD-specific is pretty far down the list.

Re: Completion collision, best way to fix

[Oliver Kiddle]

Bart wrote:
> If you're going to do that, the correct way is to use _pick_variant
> (Completion/Base/Utility/_pick_variant) to decide which flavor of "pkg"
> you have.  That way people can use zstyle to control the choice.

_pick_variant distinquishes the program variants by running them,
usually with an option such as --help. The Solaris pkg seems to take
over a second even when doing 'pkg version' so in this case, I would
simply put a test in using $OSTYPE.

The only other name clash I'm aware of is nc (netcat or nedit client). In
that case _netcat uses _pick_variant and calls _nedit.

Oliver

Re: Completion collision, best way to fix

[Phil Pennock]

On 2012-09-28 at 18:12 -0700, Danek Duvall wrote:
> On Fri, Sep 28, 2012 at 07:59:36AM -0700, Bart Schaefer wrote:
> > In practice I'm not sure any of the distribution package maintainers 
> > actually take the step of removing the "irrelevant" functions from the
> > tree; maybe some change the default fpath in /etc/zshrc or the like.
> 
> Given that I'm the zsh integrator for Solaris ...
> 
> Is there a way for the build process to put the "native" OS-specific
> directory ahead of the rest?  If not, would a patch to do that be
> appreciated?  I could take the easy way out and simply drop the BSD _pkg
> from the Solaris zsh package, but it'd be nice not to have to.

You can use --enable-additional-fpath to add entries to the default
fpath; the order used is "site", "additional", "install locations".
Since the list is scanned in order, uniqueness isn't required and you
can just replicate an entry that will appear later.

See the "INSTALL" file for details on the syntax of the option.

If runtime works, then just:
  typeset -U fpath
  fpath=(${fpath[(R)*/Solaris]} $fpath)

-Phil