bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37976: 27.0.50; Dependency reversal of seq-subseq and cl-subseq caus


From: Terje Larsen
Subject: bug#37976: 27.0.50; Dependency reversal of seq-subseq and cl-subseq causes regression when using seq from ELPA
Date: Wed, 13 Nov 2019 12:30:28 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

>>> What ended up happening now is that Emacs is using the new builtin cl-subseq
>>> from cl-extra.
>
> This new cl-subseq only exists in Emacs's `master`, right?
> So they're running Emacs `master`.
>

Yes, as mentioned, this is Emacs from `master`, since commit 
`0e4dd67aae8b10032317a29a6bd99d2d4a64c897`.

>>> But using seq-subseq from MELPA which causes an infinite
>>> loop as they depend on eachother.
>
> Why would they use "seq-subseq from MELPA" when they have the latest
> seq.el built into their Emacs `master`?
>

I am sorry to have written MELPA, but I meant ELPA. I think you can
reproduce this by installing `seq` from ELPA via package-install, which
Emacs clearly marks as an older version, so that would be questionable.

But is it that unlikely that you somehow would have the `seq` from ELPA
on your `load-path`?

>>> What is the recommended way to solve this issue? I am not controlling
>>> using seq from MELPA since I am using a package that pulls in seq from
>>> MELPA as a dependency. For now I am considering to patch the seq in
>>> MELPA.
>
> Could we have some more data, such as which package (name and version)
> pulls which version of `seq` (and how does it say "from MELPA")?
>

In ELPA there are not that many packages that depend on seq, but there
is for example `beacon` which depends on `(seq "2.14")`. In MELPA there
is a lot, for example `org-drill` which also depends on `(seq "2.14")`.

However I think `seq` won't be pulled from ELPA for these since the
dependency is already satisfied by the built-in version.

I am using NixOS and I think this issue comes from nix and how it
resolves packages. Nix will resolve Emacs package dependencies on a
system level and make sure all of them are added to your `load-path`
when launching Emacs. The unfortunate thing is that if a package depends
on `seq`, it pulls the one from ELPA since it doesn't know about the
built-in package in Emacs.

I will raise this issue on the nixpkgs instead, as it is less likely
that non-nix users will have the ELPA `seq` on their `load-path`.

>
>         Stefan "¡¿why on earth would you put `seq` on MELPA?!"

No-one put seq on MELPA, it was ELPA all-along, once again sorry for
that mistake.


Thank you for your reply and if you don't think anything needs to be
done on Emacs/ELPA side, feel free to close this issue.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]