Re: [ELPA] New package: hcel

[Yuchen Pei <id@ypei.org>]

Hi Stefan,

Thanks for your reply.
On Tue 2022-09-20 17:26:34 -0400, Stefan Monnier wrote:

> Hi Yuchen, sorry I didn't get back to you earlier,
>
>> It is a Haskell codebase explorer, using the server program provided by
>> haskell-code-explorer[2], which I ported to recent GHC version[3] and
>> I named my port / fork hcel.
>>
>> [1] https://g.ypei.me/hcel.git/tree/lisp
>> [2] https://github.com/alexwl/haskell-code-explorer
>> [3] https://g.ypei.me/hcel.git/about/
>>
>> I'm not sure whether it is unusual to submit a package that relies on a
>> self-hosted free software server program,
>
> Indeed, in many cases such modes start their life alongside the
> associated tool, but it can be nicer for users if it's available in
> GNU ELPA.

One solution is to add downloading and installing the server program
hcel to the package install process.  But I'm not sure if this is a good
idea because 1) the server program is written in Haskell not elisp and I
don't hold the copyright and 2) anyone could set up a public instance
(like the reference instance by the maintainer of the original
haskell-code-explorer) for others to use.

I think the situation is similar to say a mediawiki client that talks to
any wiki including Wikipedia, or an emacs version of h-client[1] that talks
to any h-source[2] servers, including the "official" instance
h-node.org.

[1] https://savannah.nongnu.org/projects/h-client
[2] https://savannah.nongnu.org/projects/h-source

>
> Often part of the issue is co-evolution (e.g. does it make sense to use
> `hcel.el` from last year with the current `hcel` tool and vice versa).

Right.  hc.el the emacs client talks to hcel the server using http
requests.  If the server API ever changes, hc.el could check the API
version in an API response against its supported versions and throw an
error for incompatibility.  I have not implemented that yet because the
API has not changed so far.

>
> IIUC the code you suggest we add to GNU ELPA is the one at
> https://g.ypei.me/hc.el.git, right?

Yes, I separated it out of the server program.

>
> Given the fact that this tool has a fairly narrow focus, I must admit
> that I'd prefer it doesn't eat up a two-letter file name like `hc`.
> Any chance you can rename that main file to `hcel.el`?

I applied your patch that does so.

>
> Also, I see that your package has:
>
>     ;; Package-Requires: ((emacs "28") (haskell-mode))
>
> but `haskell-mode` is currently neither in GNU ELPA nor in NonGNU ELPA
> so we can't include it in neither of them.  Is the dependency
> unavoidable (so we should first include `haskell-mode` in (Non)GNU
> ELPA), or can it be removed (and replaced with a runtime test, possibly
> allowing the use of other haskell modes such as haskell-tng-mode, which
> *is* in NonGNU ELPA)?

It seems to me haskell-mode is in NonGNU ELPA[3]?  The mode is used for
piggybacking their font-locking for the code syntax highlight.  There's
probably sufficient info in the server response for hc.el to apply its
own syntax highlighting, but it has not been a priority to implement
this functionality.  Is this needed for inclusion in ELPA?

[3] https://elpa.nongnu.org/nongnu/

Best,
Yuchen

-- 
PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
          <https://ypei.org/assets/ypei-pubkey.txt>