nongnu ELPA and slime

nongnu ELPA and slime

[Peter Hull]

Hi,

Is this list the correct place to discuss nongnu ELPA?

I've come across a problem with the latest (2.29.1) SLIME package when
installed from ELPA. Basically the package appears to install without
problems but none of its functions are registered so it cannot be
activated. There is more discussion on
https://github.com/slime/slime/issues/808

What I believe is happening is that the slime-2.29.1.tar on ELPA is
being constructed without its hand-written slime-autoloads.el file. At
install time, an autoload file is generated which doesn't work,
because the relevant functions in SLIME are not marked with autoload
cookies. The release tarball on github does have the autoloads file,
as does slime-20240125.1336 from MELPA.

Unfortunately I've only ever been a user of emacs packages so I don't
understand how it all works. Is there a way to specify that the
slime-autoloads.el file needs to be included in the package, or will
the relevant bits of SLIME need to be annotated so the generated file
is functional?

Thanks for your help,

Peter

Re: nongnu ELPA and slime

[Philip Kaludercic]

Peter Hull <peterhull90@gmail.com> writes:

> Hi,
>
> Is this list the correct place to discuss nongnu ELPA?

Sure.

> I've come across a problem with the latest (2.29.1) SLIME package when
> installed from ELPA. Basically the package appears to install without
> problems but none of its functions are registered so it cannot be
> activated. There is more discussion on
> https://github.com/slime/slime/issues/808
>
> What I believe is happening is that the slime-2.29.1.tar on ELPA is
> being constructed without its hand-written slime-autoloads.el file. At
> install time, an autoload file is generated which doesn't work,
> because the relevant functions in SLIME are not marked with autoload
> cookies. The release tarball on github does have the autoloads file,
> as does slime-20240125.1336 from MELPA.

Do you know why they don't mark their functions with autoload cookies?
Writing a manual autoload file is very unusual.

> Unfortunately I've only ever been a user of emacs packages so I don't
> understand how it all works. Is there a way to specify that the
> slime-autoloads.el file needs to be included in the package, or will
> the relevant bits of SLIME need to be annotated so the generated file
> is functional?

It would be imaginable to configure the ELPA build server to not
overwrite the slime-autoloads.el file, but I'd first like to understand
why they take this route in the first place.

FWIW the quick fix for this issue is to add this to your init.el

(autoload 'slime-mode "slime")
(add-hook 'lisp-mode-hook 'slime-mode)

> Thanks for your help,
>
> Peter

Re: nongnu ELPA and slime

[Colin Baxter]

>>>>> Philip Kaludercic <philipk@posteo.net> writes:

    > Peter Hull <peterhull90@gmail.com> writes:
    >> Hi,
    >> 
    >> Is this list the correct place to discuss nongnu ELPA?

    > Sure.

    >> I've come across a problem with the latest (2.29.1) SLIME package
    >> when installed from ELPA. Basically the package appears to
    >> install without problems but none of its functions are registered
    >> so it cannot be activated. There is more discussion on
    >> https://github.com/slime/slime/issues/808
    >> 
    >> What I believe is happening is that the slime-2.29.1.tar on ELPA
    >> is being constructed without its hand-written slime-autoloads.el
    >> file. At install time, an autoload file is generated which
    >> doesn't work, because the relevant functions in SLIME are not
    >> marked with autoload cookies. The release tarball on github does
    >> have the autoloads file, as does slime-20240125.1336 from MELPA.

    > Do you know why they don't mark their functions with autoload
    > cookies?  Writing a manual autoload file is very unusual.

    >> Unfortunately I've only ever been a user of emacs packages so I
    >> don't understand how it all works. Is there a way to specify that
    >> the slime-autoloads.el file needs to be included in the package,
    >> or will the relevant bits of SLIME need to be annotated so the
    >> generated file is functional?

    > It would be imaginable to configure the ELPA build server to not
    > overwrite the slime-autoloads.el file, but I'd first like to
    > understand why they take this route in the first place.

    > FWIW the quick fix for this issue is to add this to your init.el

    > (autoload 'slime-mode "slime")

(autoload 'slime-mode "slime") doesn't work for me.

I  need (require 'slime-autoloads) for slime from the git repository.

Best wishes

Re: nongnu ELPA and slime

[Philip Kaludercic]

Colin Baxter <m43cap@yandex.com> writes:

>>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>
>     > Peter Hull <peterhull90@gmail.com> writes:
>     >> Hi,
>     >> 
>     >> Is this list the correct place to discuss nongnu ELPA?
>
>     > Sure.
>
>     >> I've come across a problem with the latest (2.29.1) SLIME package
>     >> when installed from ELPA. Basically the package appears to
>     >> install without problems but none of its functions are registered
>     >> so it cannot be activated. There is more discussion on
>     >> https://github.com/slime/slime/issues/808
>     >> 
>     >> What I believe is happening is that the slime-2.29.1.tar on ELPA
>     >> is being constructed without its hand-written slime-autoloads.el
>     >> file. At install time, an autoload file is generated which
>     >> doesn't work, because the relevant functions in SLIME are not
>     >> marked with autoload cookies. The release tarball on github does
>     >> have the autoloads file, as does slime-20240125.1336 from MELPA.
>
>     > Do you know why they don't mark their functions with autoload
>     > cookies?  Writing a manual autoload file is very unusual.
>
>     >> Unfortunately I've only ever been a user of emacs packages so I
>     >> don't understand how it all works. Is there a way to specify that
>     >> the slime-autoloads.el file needs to be included in the package,
>     >> or will the relevant bits of SLIME need to be annotated so the
>     >> generated file is functional?
>
>     > It would be imaginable to configure the ELPA build server to not
>     > overwrite the slime-autoloads.el file, but I'd first like to
>     > understand why they take this route in the first place.
>
>     > FWIW the quick fix for this issue is to add this to your init.el
>
>     > (autoload 'slime-mode "slime")
>
> (autoload 'slime-mode "slime") doesn't work for me.

It depends on what you do.  In my case I also have a hook configured in
my configuration (the next line in the snippet you quoted), which loads
up slime upon opening a lisp-mode buffer.

>
> I  need (require 'slime-autoloads) for slime from the git repository.

The point is that this is not available on NonGNU ELPA, because
elpa-admin.el is regenerating the file.

> Best wishes