Re: Add guile-minikanren

[Christopher Allan Webber <cwebber@dustycloud.org>]

Wow, a lot of feedback!  Okay, comments inline... I'm combining replies
into one email.

Andreas Enge writes:

>> +              ;; sha256 goes here
>
> Can be dropped.

Okay, dropping!

Thompson, David writes:

> On Thu, Apr 23, 2015 at 9:17 AM, Andreas Enge <andreas@enge.fr> wrote:
>> On Wed, Apr 22, 2015 at 10:15:27AM -0500, Christopher Allan Webber wrote:
>>
>>> I named it guile-minikanren which isn't really accurate.  I'm not sure
>>> how else I could name it though?  I'd be open to suggestions!
>>
>> There is a chapter in the documentation about this:
>>    https://www.gnu.org/software/guix/manual/guix.html#Package-Naming
>> The main idea is to not think too much, but to simply use the upstream
>> project name. Here this seems to be "minikanren" without "guile-".
>> We have special rules for perl and python; maybe we also need a special
>> rule for guile?
>
> The prefix "guile-" is important here because the build system
> installs the Scheme modules into a directory that is specifically for
> Guile, not other R6RS compliant Scheme implementations.

This, and that there's a more "official" minikanren implementation; this
one is the r6rs packaging of minikanren that Ian Price made in 2012.
I considered naming it r6rs-minikanren... but you're right, it ends up
in the guile directory anyway.

It might be nice to have a mainline version of minikanren.  I'm not
sure.  There is the additional problem that the mainline minikanren has
a bug so that it does not run unpatched in Guile:

  https://github.com/miniKanren/miniKanren/issues/2

(Also I'd love to see cKanren ported to Guile, to go a little bit
off topic!  Constraints seem like a nice feature...)

>>>> +    (native-inputs `(("guile" ,guile-2.0)))
>>>
>>> "native-inputs" are used during the build of the package, which is not
>>> the case here. Is guile needed at all as an input?
>>
>> It will be needed.  The build system should compile the Scheme files,
>> but it doesn't.
>
> Even when it does this won’t be needed: there’s implicitly a Guile
> running the build script already.  :-)

Working on it!  I ran into troubles getting guild to run with the
trivial-build-system but Mark Weaver has suggested that I use the
gnu-build-system and tear out the phases I don't need since that will
set up the environment variables and stuff.  So I'm working on that...

>> As a final note, I would like to add that the 'license' field can be
>> simply 'expat', instead of using the 'non-copyleft' procedure.
>
> +1
>

I thought of this.  It's true that Guix has a convenient mechanism, but
is this true from a licensing standpoint, however?  It's straight-up
expat licensing, but when I see stuff like this:

  Copyright (c) 2005 Daniel P. Friedman, William E. Byrd and Oleg Kiselyov
  Copyright (c) 2012 Ian Price

  [...]

  The above copyright notice and this permission notice shall be
  included in all copies or substantial portions of the Software.

... it makes me think that the license has effectively required eternal
one-off copies of itself since the copyright notice must be
preserved... is it possible to separate them from this file, and put it
somewhere else?

I suspect debian-legal has already answered this one...

> Eric Bavier <ericbavier@openmailbox.org> skribis:
>
>> On 2015-04-23 13:57, ludo@gnu.org wrote:
>>>>>> +    (source (origin
>>>>>> +              (method git-fetch)
>>>>>> +              (uri (git-reference
>>>>>> +                    (url "https://github.com/ijp/minikanren.git")
>>>>>> +                    (commit
>>>>>> "10d507785eab30b0f8b47bf8bb37d880731fc031")))
>>>>>
>>>>> Is there no tarball? If possiblem we would prefer this.
>>>>
>>>> No tarball.  I would recommend that the first 7 characters of the
>>>> commit SHA be used as the package version, and this string here could
>>>> just be replaced with 'version'.
>>>
>>> Maybe make the version (string-append "0-" commit) so we can eventually
>>> increment that zero to make upgrades work, as Andreas notes?
>>> (I think upstream minikanren is frozen anyway.)
>>
>> Why not use YYYYMMDD.<7-char-sha> so that the version is less
>> arbitrary? It would still sort for upgrades.
>
> Fine with me!

Okay, I'll use that format!

> Chris, could you post an updated patch taking into account alllll these
> comments?  :-)
>
> I hope the thorough review did not drive you away already.  ;-)
> At any rate, welcome, and thanks for helping out!
>
> Ludo’.

It's good to know the community is thorough.  I will admit that my first
impression was, "this is just copying a few files, how hard of an early
submission could it be?"  But in a sense it's nice because iteration 0
was not so hard, and refining to take this feedback into account has
been a nice learning process.

Anyway, I'm working on it.  Will respond with that soon!

 - Chris