splitting off shell test framework

splitting off shell test framework

[Adam Spiers]

Hi all,

I've been pretty impressed with git's test framework, and I'm not
aware of many other (decent) shell-based test frameworks out there.
(One that springs to mind is the one used by rvm, but last time I
looked - admittedly a while ago now - it had limitations).

Recently a situation arose where I craved the ability to test
something via shell.  I did a quick proof of concept and successfully
extracted out the non-git-specific bits of git's test framework to be
used to test something entirely unrelated to git:

    https://github.com/aspiers/shell-env/tree/master/t

As it turned out to be fairly easy, I was wondering if there would be
any interest in doing this more formally, i.e. splitting off the
framework so that it could be used and improved outside the scope of
git development?  Of course this would pose the question how git would
consume this new project without any risk of destabilisation.  I'm
guessing that simply using a git submodule would solve the problem,
but ICBW ...

Just an idea.  Interesting, or terrible? :)

Regards,
Adam

Re: splitting off shell test framework

[Felipe Contreras]

On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers <git@adamspiers.org> wrote:

> I've been pretty impressed with git's test framework, and I'm not
> aware of many other (decent) shell-based test frameworks out there.
> (One that springs to mind is the one used by rvm, but last time I
> looked - admittedly a while ago now - it had limitations).
>
> Recently a situation arose where I craved the ability to test
> something via shell.  I did a quick proof of concept and successfully
> extracted out the non-git-specific bits of git's test framework to be
> used to test something entirely unrelated to git:
>
>     https://github.com/aspiers/shell-env/tree/master/t
>
> As it turned out to be fairly easy, I was wondering if there would be
> any interest in doing this more formally, i.e. splitting off the
> framework so that it could be used and improved outside the scope of
> git development?  Of course this would pose the question how git would
> consume this new project without any risk of destabilisation.  I'm
> guessing that simply using a git submodule would solve the problem,
> but ICBW ...

FWIW, the notmuch project seems to be doing the same; extracting and
using git's test framework.

> Just an idea.  Interesting, or terrible? :)

That I don't know :)

-- 
Felipe Contreras

RE: splitting off shell test framework

[Pyeron, Jason J CTR (US)]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

> -----Original Message-----
> From: Felipe Contreras
> Sent: Monday, November 12, 2012 11:44 AM
> 
> On Mon, Nov 12, 2012 at 5:37 PM, Adam Spiers <git@adamspiers.org>
> wrote:
> 
> > I've been pretty impressed with git's test framework, and I'm not
> > aware of many other (decent) shell-based test frameworks out there.
> > (One that springs to mind is the one used by rvm, but last time I
> > looked - admittedly a while ago now - it had limitations).
> >
> > Recently a situation arose where I craved the ability to test
> > something via shell.  I did a quick proof of concept and successfully
> > extracted out the non-git-specific bits of git's test framework to be
> > used to test something entirely unrelated to git:
> >
> >     https://github.com/aspiers/shell-env/tree/master/t
> >
> > As it turned out to be fairly easy, I was wondering if there would be
> > any interest in doing this more formally, i.e. splitting off the
> > framework so that it could be used and improved outside the scope of
> > git development?  Of course this would pose the question how git
> would
> > consume this new project without any risk of destabilisation.  I'm
> > guessing that simply using a git submodule would solve the problem,
> > but ICBW ...
> 
> FWIW, the notmuch project seems to be doing the same; extracting and
> using git's test framework.


The Apache Maven project is migrating to GIT right now and they just covered a long discussion on the pros and cons of this (sort of). It might be a bit of a read [1] but I can also provide some perspective. The question is asked in reverse in [2] since Maven had them separate and some suggested to merge them.

1: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3cA5D13406-474A-43E6-9708-D5D4DE9BE64C@tesla.io%3e
2: http://mail-archives.apache.org/mod_mbox/maven-dev/201210.mbox/%3c1349937687.79626.YahooMailNeo@web28903.mail.ir2.yahoo.com%3e 





[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]

Re: splitting off shell test framework

[Drew Northup]

On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers <git@adamspiers.org> wrote:
> Hi all,
>
> I've been pretty impressed with git's test framework, and I'm not
> aware of many other (decent) shell-based test frameworks out there.
> (One that springs to mind is the one used by rvm, but last time I
> looked - admittedly a while ago now - it had limitations).
>
> Recently a situation arose where I craved the ability to test
> something via shell.  I did a quick proof of concept and successfully
> extracted out the non-git-specific bits of git's test framework to be
> used to test something entirely unrelated to git:
>
>     https://github.com/aspiers/shell-env/tree/master/t
>
> As it turned out to be fairly easy, I was wondering if there would be
> any interest in doing this more formally, i.e. splitting off the
> framework so that it could be used and improved outside the scope of
> git development?  Of course this would pose the question how git would
> consume this new project without any risk of destabilisation.  I'm
> guessing that simply using a git submodule would solve the problem,
> but ICBW ...
>
> Just an idea.  Interesting, or terrible? :)

Done at least once already:

http://comments.gmane.org/gmane.comp.version-control.git/201591

-- 
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59

Re: splitting off shell test framework

[Adam Spiers]

On Mon, Nov 12, 2012 at 6:18 PM, Drew Northup <n1xim.email@gmail.com> wrote:
> On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers <git@adamspiers.org> wrote:
>> As it turned out to be fairly easy, I was wondering if there would be
>> any interest in doing this more formally, i.e. splitting off the
>> framework so that it could be used and improved outside the scope of
>> git development?  Of course this would pose the question how git would
>> consume this new project without any risk of destabilisation.  I'm
>> guessing that simply using a git submodule would solve the problem,
>> but ICBW ...
>>
>> Just an idea.  Interesting, or terrible? :)
>
> Done at least once already:
>
> http://comments.gmane.org/gmane.comp.version-control.git/201591

Nice!  So hopefully someone will submit patches to build a two-way bridge
via git subtree.  Having them diverge would be sad.

Re: splitting off shell test framework

[Adam Spiers]

I got a helpful response to the following question almost 5 years ago:

On 12 November 2012 at 23:09, Adam Spiers <git@adamspiers.org> wrote:
> On Mon, Nov 12, 2012 at 6:18 PM, Drew Northup <n1xim.email@gmail.com> wrote:
>> On Mon, Nov 12, 2012 at 11:37 AM, Adam Spiers <git@adamspiers.org> wrote:
>>> As it turned out to be fairly easy, I was wondering if there would be
>>> any interest in doing this more formally, i.e. splitting off the
>>> framework so that it could be used and improved outside the scope of
>>> git development?  Of course this would pose the question how git would
>>> consume this new project without any risk of destabilisation.  I'm
>>> guessing that simply using a git submodule would solve the problem,
>>> but ICBW ...
>>>
>>> Just an idea.  Interesting, or terrible? :)
>>
>> Done at least once already:
>>
>> http://comments.gmane.org/gmane.comp.version-control.git/201591
>
> Nice!  So hopefully someone will submit patches to build a two-way bridge
> via git subtree.  Having them diverge would be sad.

but sadly since then gmane has shuffled off its mortal coil and I can't
remember / find what this URL referred to.  Please could someone
point me at a working link?

Many thanks!
Adam

Re: splitting off shell test framework

[Jeff King]

On Wed, Aug 23, 2017 at 02:46:30PM +0100, Adam Spiers wrote:

> >> Done at least once already:
> >>
> >> http://comments.gmane.org/gmane.comp.version-control.git/201591
> [...]
> 
> but sadly since then gmane has shuffled off its mortal coil and I can't
> remember / find what this URL referred to.  Please could someone
> point me at a working link?

Try:

  https://public-inbox.org/git/?q=gmane:201591

Public-inbox uses message-ids as its primary key, but keeps a static
mapping of gmane articles to message-ids. But the corpus of gmane ids
isn't growing anymore, and public-inbox URLs can be trivially converted
to other systems which index on the message id[1].

-Peff

[1] I actually keep a local archive and convert public-inbox URLs into
    local requests that I view in mutt.

Re: splitting off shell test framework

[Adam Spiers]

On 23 August 2017 at 16:47, Jeff King <peff@peff.net> wrote:
> On Wed, Aug 23, 2017 at 02:46:30PM +0100, Adam Spiers wrote:
>> >> Done at least once already:
>> >>
>> >> http://comments.gmane.org/gmane.comp.version-control.git/201591
>> [...]
>>
>> but sadly since then gmane has shuffled off its mortal coil and I can't
>> remember / find what this URL referred to.  Please could someone
>> point me at a working link?
>
> Try:
>
>   https://public-inbox.org/git/?q=gmane:201591
>
> Public-inbox uses message-ids as its primary key, but keeps a static
> mapping of gmane articles to message-ids. But the corpus of gmane ids
> isn't growing anymore, and public-inbox URLs can be trivially converted
> to other systems which index on the message id[1].

Thanks a lot; that's super helpful!

> [1] I actually keep a local archive and convert public-inbox URLs into
>     local requests that I view in mutt.

Sounds like a neat trick - any scripts / config worth sharing?

Re: splitting off shell test framework

[Jeff King]

On Thu, Aug 24, 2017 at 12:23:05AM +0100, Adam Spiers wrote:

> > [1] I actually keep a local archive and convert public-inbox URLs into
> >     local requests that I view in mutt.
> 
> Sounds like a neat trick - any scripts / config worth sharing?

It's probably too specific to my setup, but here it is anyway.

I keep the archive in a normal maildir, which I index with the mairix
tool (you could do the same thing with maildir-utils or notmuch). New
messages get put into the maildir by mutt's auto-move feature after I've
read them.

Then I have a few keys bound in mutt:

  macro pager,index M '<pipe-message>gmane<enter>'
  macro pager,index B '<pipe-message>rmairix-gmane<enter>'

(you can tell from the names that these predate public-inbox entirely).

The "gmane" script just opens a browser pointing to the current message
in the archive, from which I then 'y'ank the URL into the clipboard or
pasting. The network round-trip was necessary for gmane, since the
article ids were not predictable. For public-inbox, it's not necessary,
but old habits die hard (and it's a nice cross-check that the link
you're sending out isn't broken).

Here's that script:

-- >8 --
#!/bin/sh

mid() {
  exec webview "http://public-inbox.org/git/$1"
}

article() {
  exec webview "http://public-inbox.org/git/?q=gmane:$1"
}

find_mid() {
  perl -ne 'if(/^message-id:\s*<([^>]+)>/i) { print $1, "\n"; exit 0 }'
}

case "$#" in
  0) id=`find_mid`
     case "$id" in
       "") echo >&2 "fatal: unable to extract message-id from stdin"; exit 1 ;;
        *) mid "$id" ;;
     esac
     ;;
  1) case "$1" in
       *@*) mid "$1" ;;
         *) article "$1" ;;
     esac
     ;;
  *) echo >&2 "fatal: don't know how to handle $# arguments"; exit 100 ;;
esac
-- 8< --

The "webview" command is just a personal wrapper that decides which
browser to use. You could replace it with "firefox" or "chromium" or
whatever.

The "rmairix-gmane" script picks out gmane/public-inbox references and
re-opens them in mutt. It looks like this:

-- >8 --
#!/usr/bin/env perl
use URI;
use URI::Escape;

if (@ARGV) {
  show_gmane_article($_) foreach @ARGV;
}
else {
  while(<>) {
    if (m{http://[^/]*gmane.org/[-\w/.]+}) {
      show_gmane_url($&);
    }
    if (m{https?://public-inbox.org/git/([^/]+)}) {
      show_mid(uri_unescape($1));
    }
  }
}
exit 0;

sub show_mid {
  system("rmairix -t m:" . quotemeta(shift) . " </dev/tty");
}

sub show_gmane_url {
  my ($group, $article) = extract_article(shift);
  show_gmane_article($article);
}

sub show_gmane_article {
  my $article = shift;
  my $mid = gmane_to_mid($article);
  show_mid($mid) if defined $mid;
}

sub gmane_to_mid {
  my $want = shift;

  open(my $map, "-|", qw(gunzip -c), "$ENV{HOME}/.gmane-to-mid.gz");
  while (<$map>) {
    chomp;
    my ($nr, $mid) = split / /, $_, 2;
    return $mid if $nr == $want;
  }
}

sub extract_article {
  my @path = URI->new(shift)->path_segments;

  # first one is always empty in absolute URL
  shift @path unless length($path[0]);

  # group is always next
  my $group = shift @path;

  # and then look for numbers starting from the back. E.g.,
  # focus=N for threads, or just "N" for articles
  while (@path) {
    local $_ = pop @path;
    return ($group, $&) if /\d+/;
  }

  return ($group, undef);
}
-- 8< --

The two extra bits you'd need are:

  - the ~/.gmane-to-mid.gz mapping. I don't remember if I made this
    myself or stole it from one that Eric posted. I'm happy to share if
    anybody wants it.

  - rmairix is a personal wrapper around mairix that ssh's to my imap
    server to do the search and then starts mutt on the result.

    Naturally I also use it for general queries like

      rmairix -t f:peff sanitize thread

I hope that helps.  I suspect it may be more useful to people as
inspiration and not as running code. I'm happy to answer any questions
or give any guidance I can.

-Peff