unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
To: Achim Gratz <Stromeko@nexgo.de>, emacs-devel@gnu.org
Subject: Re: Installing binaries with package.el
Date: Thu, 9 Feb 2017 15:11:58 -0500	[thread overview]
Message-ID: <b63f3127-0d10-39b6-85ed-b19909735676@gmail.com> (raw)
In-Reply-To: <87zihvb0zr.fsf@Rainer.invalid>

On 2017-02-09 14:47, Achim Gratz wrote:
> Clément Pit-Claudel writes:
>> Sorry, maybe my original question wasn't clear.  The question was:
>> I wrote a command line utility in ELisp (it doesn't provide
>> interactive commands; just a command line interface).  What's the
>> preferred way for users to install it?
> 
> I understood that to be the case, but it's a very surprising use of 
> package.el and ELisp.

I don't know how common it is, but the support for this has been there this version 22 (shebang lines are skipped by the ELisp interpreter, and emacs can be started with --script).  There seems to be a fair number of uses on Github (https://github.com/search?q=emacs+--script&type=Code&utf8=✓)

> As I said I don't really have a suggestion at
> the moment, but this particular use case should not be handled as an
> "Emacs package".  You use Emacs as a VM for some scripting here.

Not entirely.  The above was a bit of an exaggeration: the package does provide interactive commands, in addition to the CLI.  And it has dependencies on other Emacs packages, meaning that it isn't trivial to just distribute it as (say) a Debian package.

>>> I simply don't think that wrapper scripts and/or compiling
>>> binaries is appropriate for ELPA packages, it just opens one big
>>> can of worms that I don't really want to deal with in any way.
>> 
>> I don't understand this part too well.  Are you saying that ELPA
>> isn't the right place to distribute a command line application
>> written entirely in ELisp?  (Note that the task that I'm describing
>> has nothing to do with compiling binaries — sorry if that wasn't
>> clear).
> 
> Well, I would want to distinguish between Emacs packages proper and 
> Emacs as a scripting VM.

Do you know of other systems that distinguish in that way? The ones that I'm familiar with (cabal, pip, and opam) are all used to install both applications and libraries.  Do you think there's something special about Emacs Lisp that makes it different?

> The more I think about it, package.el should guarantee that it
> doesn't write outside the package directory unless it has explicit
> user consent.

That's fine by me: I have no problem with writing to e.g. elpa/bin/.  And I'd be even happier if this was taken care of by package.el.
I don't have objections to prompts, either.

Clément.



  reply	other threads:[~2017-02-09 20:11 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-07  2:09 Installing binaries with package.el Clément Pit--Claudel
2017-02-07  5:29 ` Marcin Borkowski
2017-02-07  5:33   ` Clément Pit-Claudel
2017-02-07  7:22     ` Marcin Borkowski
2017-02-07 13:12       ` Clément Pit-Claudel
2017-02-07 15:07         ` Ted Zlatanov
2017-02-07 16:15           ` Clément Pit-Claudel
2017-02-07 19:40             ` Ted Zlatanov
2017-02-09 13:10               ` Stefan Monnier
2017-02-09 16:20                 ` Ted Zlatanov
2017-02-09 17:39                   ` Stefan Monnier
2017-02-09 19:36                     ` Ted Zlatanov
2017-02-09 22:43                     ` Stephen Leake
2017-02-08 18:40     ` Andreas Politz
2017-02-09 15:33       ` Stefan Monnier
2017-02-09 21:55         ` Andreas Politz
2017-02-10  6:09           ` Stefan Monnier
2017-02-07 16:05 ` Stefan Monnier
2017-02-07 16:16   ` Clément Pit-Claudel
2017-02-07 16:58     ` Aurélien Aptel
2017-02-07 17:45       ` Stefan Monnier
2017-02-07 20:17 ` Achim Gratz
2017-02-07 21:58   ` Clément Pit-Claudel
2017-02-07 23:34     ` Kaushal Modi
2017-02-08  1:35       ` Clément Pit-Claudel
2017-02-08 18:52     ` Achim Gratz
2017-02-08 19:17       ` Andreas Politz
2017-02-08 19:44         ` Achim Gratz
2017-02-08 21:36       ` Clément Pit-Claudel
2017-02-09 19:47         ` Achim Gratz
2017-02-09 20:11           ` Clément Pit-Claudel [this message]
2017-02-09 22:48           ` Stephen Leake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b63f3127-0d10-39b6-85ed-b19909735676@gmail.com \
    --to=cpitclaudel@gmail.com \
    --cc=Stromeko@nexgo.de \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).