Re: using use-package

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Indeed. Cask doesn't have that option at the moment. It's not hard,
>> though
>
>> (let ((dir (make-temp-name "cask")))
>>   (cask-cli/package dir)
>>   (package-install-file
>>       (concat dir
>>          default-directory ".tar")))
>
> AFAICT this again is not what I want: it takes your source code, turns
> it into a tarball, then installs a copy of it elsewhere.
> Whereas you'd really want the package to be installed *in place*
> (e.g. so that C-h f gives you hyperlinks that jump to the actual real
> editable source under version control).

Yes, that would be nice to have, although it has risks. First, it
assumes that what is installed actually is the source code, which is not
always the case. So, dash.el has autogenerated documentation. And
tangled code from an org file would be another counter.

Second, it also means that the developer of a package is not using them
same installation proceedure as their users. This is the way I develop
at the moment, but I am not convinced it is a good thing. If the code
that achieves your aim is out of sync with the package.el equivalent,
then the world has not been helped.

As an alternative, why not expand C-h f with a "redirect functionality".
So, you install your own packages using "cask install-to-local". In
normal running all the source code would load from ~/.emacs.d/elpa. But
C-h f would say

blah-blah is a compiled Lisp function in (~/.emacs.d/elpa/blah.el) but
developed in (~/my-emacs-dev/blah/blah.eh).

Pimping `load' so that as well as printing "loading blah.elc but blah.el
is newer", it would print "loading blah.el but the development file
blah.el is newer". On seeing this error message, the developer would
know to do "cask install-to-local" again.

This would facilitate live-editing and coding of ELPA packages, while
meaning that ELPA package developers would still be using the same
install proceedures as their users.



>> that sort of thing (untested for demonstration purposes only).  The
>> easiest way to have a package look like it was installed via package.el
>> is surely to install it via package.el!
>
> But it does not mimic what you do with your "packages not
> installed via package.el".

No!

Phil