GNU bug report logs - #37976
27.0.50; Dependency reversal of seq-subseq and cl-subseq causes regression when using seq from ELPA

Previous Next

Full log

View this message in rfc822 format

From: Terje Larsen <terlar <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 37976 <at> debbugs.gnu.org
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

Stefan Monnier <monnier <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.