Re: Patches for elpa-admin

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> I think this list is "a bit over the top", but feel free to keep it.
>> OTOH, I think "markdown" should come first since that's what's used on
>> `elpa.gnu.org`.
>
> On that topic, what program is markdown?  On Debian there seem to be a
> number of alternatives:
>
>         $ apt-file search /usr/bin/markdown | grep /markdown$
>         discount: /usr/bin/markdown
>         libtext-markdown-perl: /usr/bin/markdown
>         markdown: /usr/bin/markdown

It's `markdown` :-)

> Considering that more often than not what we are actually rendering is
> "GitHub flavoured markdown" (https://github.github.com/gfm/), it might
> make sense to use an implementation that takes this into consideration.

There are indeed a few pages which rely on features not supported by
`markdown` :-(

`elpa.gnu.org` mostly uses `markdown` because I have no idea which
implementation is better/worse, so I went with the "obvious" choice.

>> I think this optimization is not worth its cost.
> The reason I had to add this was that if using Guix, I cannot rely on
> `elpa--markdown-executable' to find what is installed, since that is
> evaluated on the host system.

Oh, right, I see, sorry.  But I guess this argues against
auto-discovering which executable to use and just rely on
an `elpaa-markdown-program` configuration variable instead (and catch an
execution error, for graceful degradation).

>> To be honest, I'm not thrilled about adding support for more container
>> systems to `elpa-admin.el` because it's not its focus.  The containers
>> are important on `elpa.gnu.org` because I'm a bit paranoid about running
>> arbitrary software on a central server that could conceivably be
>> a target for an attack.  But for most other uses it seems that setting
>> `elpaa--sandbox` to nil will do the job just fine if you don't want to
>> install `bwrap`.
>
> It is not only that, it is also the dependencies that someone might or
> might not have installed when wanting to contribute to ELPA.  By using
> Guix, the right tools are automatically provided, which could also be
> extended for non-sandbox elpa--call invocations.  The error messages
> generated if something goes wrong (e.g. missing makeinfo/install-info,
> imagemagick), can be hard to parse, and this approach just circumvents
> the issue entirely.

You mean to help the users get their local build to work even when they
don't have all the needed packages installed?
Or do you mean to help the users get their local build to fail when they rely
on packages not available in `elpa.gnu.org`?
Or both?

Maybe this can be obtained more reliably with a `guix shell` call
wrapping the whole Emacs invocation rather than only wrapping the
sandboxed subprocesses?
[ You might be able to specify the same Emacs version as the one
  installed on `elpa.gnu.org`.  ]

>> More interesting would be to add support for this kind of sandboxing in
>> Emacs itself (so ELisp's Flymake support can use it); and some years
>> from now `elpa-admin.el` will then be able to ditch its own sandboxing.
> I have actually been looking into implementing a TRAMP backend that
> would tunnel all communication through a Guix shell.  I think in that
> case Flymake should be able to make use of that.

That sounds nice.  We'd need a solution that can be made to work
"everywhere", so the API should be sufficiently generic that it can make
use of various sandboxing systems.

>>> I understand why org can be dangerous, but markdown shouldn't be able
>>> to have any side effects?)
>> Yes, and 640kB should be enough for everyone.
> Ok, I see.

BTW, if we do opt for a more fanciful markdown processor, I wouldn't be
surprised to hear that some of them do "funny" things like follow some
of your symlinks (e.g. to give you warnings if they point nowhere) ;-)

> I will wait a bit to implement the changes i mentioned.

Looking forward to them, thanks.


        Stefan