Re: [NonGNU ELPA] New package: flymake-guile

[Philip Kaludercic]

Distopico <distopico@riseup.net> writes:

> On 2023-08-31, Philip Kaludercic <philipk@posteo.net> wrote:
>
>> Distopico <distopico@riseup.net> writes:
>>
>>> Hi all!
>>>
>>> I'm the author of a new package `flymake-guile` and I
>>> would like to include it in Nongnu ELPA.
>>
>> Just to be sure, you are sure you don't want to include your package in
>> GNU ELPA?
>>
>>> Here the repo: https://framagit.org/flymake-backends/flymake-guile
>>
>> I am not familiar with the "flymake-quickdef" package, but it doesn't
>> seem to be much shorter than just defining a regular flymake backend.
>> As there have been some discussions wrt providing a kind of DSL for
>> Flymake backends, I am not sure if adding flymake-quickdef would be that
>> constructive at this point.  Would you consider updating your package to
>> not use the dependency?  You can check out other flymake-... modes in
>> GNU and NonGNU ELPA for inspiration.
>>
> Thank you for your feedback, For now I'm fine sending it to NonGNU ELPA,
> and for now I would like to keep `flymake-quickdef`, I have plans to
> write other backend and I don't wanna repeat the same validations and
> code over and over, I'll switch to the DLS when it is implemented.

FWIW it already exists in this form 
https://github.com/mohkale/flymake-collection.

And just to make sure, you are certain you want to implement this on top
of a DSL?  I have to admit that I am really not a fan of the way that
flymake-quickdef is implemented, but one redeeming feature appears to be
that you could macroexpand it away, then clean the code up.

>>> ;;; Commentary:
>>>
>>> ;; Flymake backend for GNU Guile using `guild' compile.
>>> ;;
>>> ;; Usage:
>>> ;;   (require 'flymake-guile)
>>> ;;   (add-hook 'scheme-mode-hook 'flymake-guile)
>>
>> It would probably make sense to autoload the `flymake-guile' function,
>> so that it is not necessary to require it in a user configuration.
>>
> It already have autoload, I just update the commentary there.

1+

>>
>> Are you sure the README.md is right thing to include here?  It includes
>> installation instructions, that are usually redundant when you install
>> the package using package.el.  I would recommend writing out the
>> "Commentary" section in flymake-guile.el with a brief description of
>> what package and its entry points.
>>
>> Also, the package appears to include files that needn't be distributed
>> in the release tarball, such as .envrc and guix.scm.  It would be nice
>> if you could track these and future files of this type in a .elpaignore
>> file, to instruct the build server that they should be removed before
>> packaging.
>>
> Updated in the last version ignoring those file and removing the README
> declaration.
>
> Thank you!

Distopico <distopico@riseup.net> writes:

> v1 -> v2: Remove unnecesary README and ignore files.
>
>
> From 1f683e46e59f5ebff923b493aa911e489ecd7bb0 Mon Sep 17 00:00:00 2001
> From: Distopico <distopico@riseup.net>
> Date: Wed, 30 Aug 2023 20:53:27 -0500
> Subject: [PATCH v2 2/2] * elpa-packages (flymake-guile): New package
>
> ---
>  elpa-packages | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 93e7c38600..e80486aec6 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -223,6 +223,9 @@
>   (flymake-quickdef      :url 
> "https://github.com/karlotness/flymake-quickdef.git";
>    :readme "README.md")
>  
> + (flymake-guile              :url 
> "https://framagit.org/flymake-backends/flymake-guile.git";
> +  :ignored-files (".envrc" "guix.scm"))

It would be preferable to track this information in your own repository,
instead of having to update the info in the future in elpa-packages.

Also, it is totally fine to add both packages in a single patch.