[bug#34959] Acknowledgement ([PATCH] Add Multiple Common Lisp Packages)

[Katherine Cox-Buday <cox.katherine.e@gmail.com>]

Ricardo Wurmus <rekado@elephly.net> writes:

Hey Ricardo, thanks for the review. I expect to continue work on this
tomorrow, but I wanted to check in on a few things before I get going.

> We usually expect one commit per independent change.  Could you please
> split up this patch into multiple commits?  You can group package
> variants like “sbcl-trivial-backtrace” and “cl-trivial-backtrace”, but
> separate packages generally each should have their own commit.

This will be a non-trivial amount of work, and these will have to be
chained against each other since this patch forms a dependency graph.
Given that, can you discuss the benefits of splitting these into
separate commits? Also is it multiple commits, one patch? Or multiple
patches?

>> +(define-public sbcl-trivial-backtrace
>> +  (let ((commit-hash "ca81c011b86424a381a7563cea3b924f24e6fbeb"))
>> +    (package
>> +     (name "sbcl-trivial-backtrace")
>> + (synopsis "Portable simple API to work with backtraces in Common
>> Lisp")
>> + (description "On of the many things that didn't quite get into the
>> Common Lisp standard was how to get a Lisp to output its call stack
>> when something has gone wrong. As such, each Lisp has developed its
>> own notion of what to display, how to display it, and what sort of
>> arguments can be used to customize it. trivial-backtrace is a simple
>> solution to generating a backtrace portably.")
>
> Please break up long lines like this.  Please run “./pre-inst-env guix
> lint sbcl-trivial-backtrace”, which will tell you about this problem.

I did run linting, but I wasn't sure how to break up description
strings. If I just do line-breaks, will that be OK?

>> +     (home-page "https://common-lisp.net/project/trivial-backtrace/")
>> +     (license license:bsd-style)
>> +     (version (string-append "0.0.0-" (string-take commit-hash 7)))
>
> Please use “git-version” here.  Please also use a revision string, which
> allows us to build version strings that can be sorted, e.g. when the
> base version is unchanged and a newer commit is “smaller” than the
> previous one.
>
>> +     (source
>> +      (origin
>> +       (method git-fetch)
>> +       (uri (git-reference
>> +             (url "https://github.com/gwkkwg/trivial-backtrace.git")
>> +             (commit commit-hash)))
>
> Throughout you can use “commit” instead of “commit-hash” — there is no
> naming conflict.

Yes, I know. I preferred `commit-hash` because that's what it is -- not
an actual commit. Do we standardize this much, down to variable names?

-- 
Katherine