Re: Anyone wants to join Zsh-Suite project, tools with integrations for Zsh software development

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On 29 June 2018 at 08:15, Marc Chantreux <eiro@xxxxxxxxx> wrote:
> hello Sebastian,
>
>> Has anyone a testing framework or other project that could
>> be part of a "zsh-suite"
>
> i don't know what are the crietia to be a part of zsh-suite.
> for the uze project, i wrote a TAP (https://testanything.org/)
> emiter inspired by Test::More ().

I see the zsh-suite as a collection of self-contained tools and
libraries. By self-contained I mean I don't like dependencies
spreading in exponential or so speed and things ending up as 1000
modules installed by node.js. Then, on the other hand, going outside
zsh code feels a bit refreshing. Integration is a good thing (if not
exponential, etc.), and for test framework Perl use is not a problem,
it's even nice.

> but everything is written using the uze convention and helpers.
> i would be pleased to be part of a larger project but i'm really
> bound to some "good practices" i developped over years. for example
> uze use those options and i'm not open to discussion about
> it (because reliability and readability).
>
>     braceccl extendedglob globstarshort
>     rcquotes promptbang promptsubst
>     nohashdirs pathdirs
>     nounset warncreateglobal
>     pipefail shinstdin
>
> also: i use "alternative syntax" as a first choice and really encourage
> it

Your syntax gives good impression. When coding Zsh scripts and the
project gets bigger, one can have an impression of the code being
logy, sluggish-looking. So for example I wrote a logging library,
which is characterized by use of <( the_logger ) process substitution,
yielding mysql, sqlite, etc. backend support and 0-delays in
foreground producer-process. But it doesn't feel nice to announce it,
because I see people reacting to it in terms of "such project in Zsh?
it must be logy". I of course fight with any logy part of my code,
sometimes it's not possible, and I think your syntax and style is
contrary to logy. Zsh-Suite should be good quality code explicitly
without logy parts and I think you could help with this.

> Back to TAP.zsh
>
> the idea behind that is to have a simple implemetation to
> give me the ability to reuse all the tooling already written
> for TAP and JUnit (because there is a converter).
>
> here is an exemple of test suite
>
> https://github.com/zsh-uze/http-tools/blob/master/t/100_json.t

I read the source (TAP.zsh), it's not long, I can agree with
namespaces for whole Zsh-Suite because it seems to force not-logy
looking code (the same with alternate syntax). To compare, the bats
test file I mentioned:

https://github.com/zdharma/git-url/blob/master/test/short.bats

I would miss this syntax: the conditions enumerations in [ ... ]\n[
... ]..., but TAP.zsh integrates with other stuff so there's no clear
winner. Zsh-Suite could provide 2 test suites, they would probably
differ in details and user would have a choice.

> if you clone the repo and zsh is already installed, you
> can have a test report using
>
>     prove -ezsh -r t
>
> prove comes with perl, it has a lot of plugin
> (html reports for example)

That's nice feature.

>> I have Zshelldoc
>
> for the moment, i use inline pod strings
>
> : <<=cut
>
> =head1 why?
>
> this is cool because i can just run
>
>     perldoc my/zsh/lib.zsh
>
> to have a manpage
>
> =cut
>
> but i'm not bound to this.

Here is the situation I've described earlier: Zshelldoc, coming with
impression of logy Zsh code somewhat glued together, and perldoc which
has a normal aura. Again, user can have a choice. To defend Zshelldoc
which lost at start ;), it has a function-extraction code (I wrote
some unit tests using this code, it extracts functions, then autoloads
them and tests them) and generates call-trees and reverse-call-trees
for each function. Zsh-Suite could do something to convey the message
that it's not weekend top-down script logy coding.

-- 
Best regards,
Sebastian Gniazdowski