emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to install documentation in sub-directory with Package VC?


From: Philip Kaludercic
Subject: Re: How to install documentation in sub-directory with Package VC?
Date: Sun, 09 Apr 2023 21:55:15 +0000

Jonas Bernoulli <jonas@bernoul.li> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> We only provide :url, and where appropriate :branch, :vc-backend and
>>> :maintainer.  
>>
>> :maintainer is currently not used
>
> Removed.
>
> Could you please ping me when you add new properties?

I don't see the point of adding support for it to package-vc, that is to
say that I don't know what would want to make use of it.

>> (TBH I am not sure what the point of it is in elpa-admin to begin
>> with),
>
> Sending emails to a package's maintainer.  It is used to send every
> pushed commit for example.

Every commit?  From what it see being done in elpa-admin.el it is
invoked when a package fails to build and on releases (as is the case
when a maintainer is listed in the package header).

>>> We don't set :doc or :lisp-dir (yet?).
>>
>> Do you think it could be possible to support :doc and :lisp-dir.  IIUC
>> the issue is that MELPA only accepts a list of files to include when
>> bundling a package (:files) and the build system would have to infer
>> what what is?
>
> Why is :doc needed?  I think package-install simply runs makeinfo on all
> texi files, but of course it can rely on them being at the top-level.

I don't see that package-install attempts anything like that.

> It might end up trying (and failing) to directly process gpl.texi and
> similar.  But still, cannot package-vc simply do that too?

Sure, that can be done.  There was just no need for that up until now
considering that ELPA added :doc provides the information.

> The value of :doc can also be an org file and we cannot just blindly try
> to transcode *all* org files to texi.  But Melpa doesn't support
> exporting ort to texi, so packages distributed there cannot assume that
> that happens.  (I wish Melpa supported this and I actually implemented
> it, but the main Melpa maintainers didn't want to merge it for security
> reasons.)

Hmm, understandable.  As long as MELPA wouldn't install a manual in
these cases, I think it is tolerable if package-vc doesn't do so either.

> I am not sure determining :lisp-dir from :files on the archive's side,
> is easier and/or more reliable than package-vc doing it itself based
> solely on what it finds in the latest commit.  In Borg I use "if lisp/
> exists, then use that, else use ./" and that works for 99% of all
> packages.

What package-vc does is check both "lisp" and "src" checking if they
contain .el files.  Good to know that this works well enough.

> I think it would be better to first try to add some heuristics to
> package-vc.  If that doesn't work well enough, we can still later
> make package-build generate more elpa-admin-style metadata.

Yeah, it should all work well enough for now, I guess the only way to
improve this is to deal with real-world edge-cases that are discovered
over time.

-- 
Philip Kaludercic



reply via email to

[Prev in Thread] Current Thread [Next in Thread]