Replace deprecated dash-functional dependency #9

2021-02-19T14:03:49Z

basil-conto commented

2021-02-19 14:03:49 +00:00

(Migrated from github.com)

Dash 2.18.0 now subsumes dash-functional.

See https://github.com/magnars/dash.el/blob/master/NEWS.md#from-217-to-218

Dash 2.18.0 now subsumes `dash-functional`. See https://github.com/magnars/dash.el/blob/master/NEWS.md#from-217-to-218

dickmao commented

2021-02-19 15:09:04 +00:00

(Migrated from github.com)

Great.

dickmao commented

2021-02-19 19:58:59 +00:00

(Migrated from github.com)

You are good if the user only dips from the ELPA pool and keeps dash in "dash-2.16", but the majority of emacs users get their dash from melpa. So if said melpa user has a super-antiquated dash install in "dash-19990101.1600" (melpa throws away "2.18" and tags folders with a 12-digit timestamp), the package-install will not update his dash to 2.18 because 19990101 is numerically greater than 2.18.

Something to keep in mind when systematically changing the version requirements of third-party libs.

You are good if the user only dips from the ELPA pool and keeps dash in "dash-2.16", but the majority of emacs users get their dash from melpa. So if said melpa user has a super-antiquated dash install in "dash-19990101.1600" (melpa throws away "2.18" and tags folders with a 12-digit timestamp), the package-install will not update his dash to 2.18 because 19990101 is numerically greater than 2.18. Something to keep in mind when systematically changing the version requirements of third-party libs.

basil-conto commented

2021-02-19 20:12:28 +00:00

(Migrated from github.com)

I know, but that is a problem with MELPA, not with Package-Requires. The version strings used by MELPA are technically incompatible with the Package-Requires Emacs header, and thus using them is a kludge.

MELPA users should be aware of the fact that they are using development snapshots, and should just upgrade their packages when issues arise, rather than expecting the packages they use to use non-conformant Package-Requires headers.

Elisp has the notion of package versions built into the language (e.g. defcustom's :package-version tag), and the canonical version of the latest release of Dash is 2.18.0, not 20210210, just because MELPA says so.

Something to keep in mind ;).

I know, but that is a problem with MELPA, not with `Package-Requires`. The version strings used by MELPA are technically incompatible with the `Package-Requires` Emacs header, and thus using them is a kludge. MELPA users should be aware of the fact that they are using development snapshots, and should just upgrade their packages when issues arise, rather than expecting the packages they use to use non-conformant `Package-Requires` headers. Elisp has the notion of package versions built into the language (e.g. `defcustom`'s `:package-version` tag), and the canonical version of the latest release of Dash is `2.18.0`, not `20210210`, just because MELPA says so. Something to keep in mind ;).

dickmao commented

2021-02-19 20:52:10 +00:00

(Migrated from github.com)

Haha, well, as much as I want to make the rules, I alas am beholden to them. Since my packages all live on melpa, I can safely assume my users, which I can count on one hand, would benefit from the bastardized datetime Package-Requires, but you're right -- most people just upgrade "when issues arise."

Haha, well, as much as I [want to make the rules](https://github.com/melpa/melpa/issues/2955#issuecomment-515690278), I alas am beholden to them. Since my packages all live on melpa, I can safely assume my users, which I can count on one hand, would benefit from the bastardized datetime `Package-Requires`, but you're right -- most people just upgrade "when issues arise."

basil-conto commented

2021-02-24 13:38:12 +00:00

(Migrated from github.com)

FWIW, the following devel versions of GNU ELPA and NonGNU ELPA don't suffer from the same versioning issues, so I'd recommend them, especially the NonGNU one, as an alternative to MELPA.

FWIW, the following `devel` versions of [GNU ELPA](https://elpa.gnu.org/) and [NonGNU ELPA](https://elpa.nongnu.org/) don't suffer from the same versioning issues, so I'd recommend them, especially the NonGNU one, as an alternative to MELPA. * https://elpa.gnu.org/devel/ * https://elpa.nongnu.org/nongnu-devel/

dickmao commented

2021-02-24 14:19:21 +00:00

(Migrated from github.com)

Evil will always triumph because good is dumb -- Spaceballs (1987)

Which is not to say melpa is "evil" or that FSF is "dumb," but rather to say a marketplace encumbered by ideological purity (GNU ELPA) will always fall by the wayside to one that isn't so encumbered. NonGNU ELPA is a too-little-too-late effort that, at this point, cannot overcome melpa's entrenched network effect in the minds of most emacs users.

> _Evil will always triumph because good is dumb_ -- Spaceballs (1987) Which is not to say melpa is "evil" or that FSF is "dumb," but rather to say a marketplace encumbered by ideological purity (GNU ELPA) will always fall by the wayside to one that isn't so encumbered. NonGNU ELPA is a too-little-too-late effort that, at this point, cannot overcome melpa's entrenched network effect in the minds of most emacs users.

basil-conto commented

2021-02-24 14:30:03 +00:00

(Migrated from github.com)

NonGNU ELPA is a too-little-too-late effort that, at this point, cannot overcome melpa's entrenched network effect in the minds of most emacs users.

I never suggested it can or should, and that's not why it was created ;).

> NonGNU ELPA is a too-little-too-late effort that, at this point, cannot overcome melpa's entrenched network effect in the minds of most emacs users. I never suggested it can or should, and that's not why it was created ;).

Sign in to join this conversation.

No reviewers