Re: feature/package-vc has been merged

[Björn Bidar]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>> I noticed recently that some external packages such as projectile where
>>>> copied but not to the extend or why that they are useful.
>>> I am afraid I don't understand the issue you are describing.  Could you
>>> be more concrete?
>> The package is copied but not as good because in the end it misses some
>> features, it doesn't feel as polished. I don't have a direct example
>> except missing features like no build system integration.
>> It is just to bare bone.
>
> I don't know what you mean by "The package is copied".  Then when you
> say "not as good": as good as what?  Same for "as polished": as polished
> as what?
>
> I'm also not sure even what you mean by "the package": are you talking
> about the tarball for `projectile` on NonGNU ELPA?
>
>> First of all I Didn't know about these elpa-packages but there are two
>> cases where I think custom commands could be needed such as packages
>> with native modules or some that require bootstrapping their build
>> system by means such as autotools.
>
> All the packages I have found which used autotools were easy to convert
> to rely on the normal build process for ELPA packages.
>
> For those packages which require building other artifacts, such as
> `pdf-tools` or `libpq`, the current build recipe does not support that
> at all because it was designed for elpa.gnu.org where we don't
> distribute binaries compiled for specific architectures.
> So instead, the build needs to happen during `package-install` and that
> depends on the ELPA protocol which does not include any special support
> for that :-(
> Luckily it can be solved by appropriate ELisp code in the package, which
> can trigger compilation of the artifact either during `package-install`
> or later when the package is actually used.
> It's not ideal, admittedly, but given the requirement to have something
> that can work across various packaging systems (`package-install`,
> `package-vc-install`, and possibly others), it's not that bad.


The side effect of that process is that there's no standartized way for
these packages to require native modules is that building those packages
in build systems isn't standartized, these packages have to be convinced
to not build binaries while Emacs run but take the prebuild binaries
from the package manager.

For packages provided by the package manager or which live for other
reasons in /usr there no separate path for native packages/modules.
Unless a separate load path is added manually they are not found in /usr/lib.

> I'm hoping that we'll develop a "standard" way to do it in the form of
> some ELisp function/macro so that `pdf-tools`, `libpq`, etc... can
> simply include a line or two of ELisp code which says how to compile
> their artifact (possibly just running `make`, or `ninja`, ...).

I'm not sure if that is always the best solution, maybe Melpa isn't the
best place such packages.

But just don't run them inside Emacs itself and not synchronously.

Br,

Björn