Distributing haskell-mode on NonGNU ELPA

Question

Distributing haskell-mode on NonGNU ELPA

phikal opened this issue 3 years ago · 34 comments

As mentioned in a commit comment, I am preparing a few packages for inclusion in NonGNU ELPA. Among these is haskell-mode.

The ELPA build-system assumes a new package is released, whenever the version tag is bumped, but haskell-mode does not include a header, as it is distributed by MELPA, that adds a version tag before packaging.

Currently, the plan is to manually tag the last release, but to avoid having to manually update the version tag for each release, it would be helpful if a version tag could be added to haskell-mode.el itself, when the next release is being prepared.

monnier commented 2 years ago

Pi..ing?

Answer 1 · 2021-08-07T23:09:56.000Z

Just as an update, the package has been added to NonGNU, with a manually tagged commit for now: https://elpa.nongnu.org/nongnu/haskell-mode.html

Answer 2 · 2021-08-10T13:54:43.000Z

While I'm not averse to distributing this on NonGNU ELPA in due course, I'm honestly not super happy that it has happened without any any feedback or buy-in from the Haskell Mode maintainers.

Answer 3 · 2021-08-10T14:29:40.000Z

I understand your complaint, and if you wish it can be removed for the time being, or at least until others weigh in.

Answer 4 · 2021-08-10T16:25:56.000Z

I'd probably prefer that, please, because I want to understand and manage the whole process so that we'll know that future releases will get tagged and distributed properly.

Answer 5 · 2021-08-21T17:28:22.000Z

Sorry for the delay, but the package has been removed now: https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/?id=6f642491e2cd5007c06c3d1ca2c11315185459b8.

Answer 6 · 2021-08-24T09:24:03.000Z

Thanks, appreciated. Let's leave this issue open to record the wish.

Answer 7 · 2021-08-25T12:07:11.000Z

No problem! I hope that it will be possible to install haskell-mode OOTB some day, so if there are any issues I'd be glad to help.

Answer 8 · 2021-10-19T19:21:07.000Z

Has there been any progress on this issue?

Answer 9 · 2022-05-27T09:19:25.000Z

Friendly ping to know the status of this. :)

Answer 10 · 2022-05-27T09:42:24.000Z

To my knowledge, all that has to be done is to add a Version header.

Answer 11 · 2022-09-16T16:10:47.000Z

ping @purcell?

Answer 12 · 2022-11-02T02:19:10.000Z

FWIW, I just re-added haskell-mode to the elpa-packages file in NonGNU ELPA:
While it was removed from that file, it was never actually removed from NonGNU ELPA itself (because of a missing feature in elpa-admin.el which made it unable to remove a package from the archive-contents), so this doesn't make much difference in practice.
But the problem in elpa-admin.el file is about to be fixed, and in the mean time the hcel package was added to GNU ELPA, and it uses haskell-mode to highlight its code, so we'd rather not remove haskell-mode from NonGNU ELPA any more.

Answer 13 · 2022-11-02T06:46:56.000Z

FWIW, I just re-added haskell-mode to the elpa-packages file in NonGNU ELPA: While it was removed from that file, it was never actually removed from NonGNU ELPA itself (because of a missing feature in elpa-admin.el which made it unable to remove a package from the archive-contents), so this doesn't make much difference in practice. But the problem in elpa-admin.el file is about to be fixed, and in the mean time the hcel package was added to GNU ELPA, and it uses haskell-mode to highlight its code, so we'd rather not remove haskell-mode from NonGNU ELPA any more.

Is the version on NonGNU ELPA up to date with the latest changes of the MELPA one?

Answer 14 · 2022-11-02T06:54:59.000Z

manuel-uberti ***@***.***> writes:

> FWIW, I just re-added `haskell-mode` to the `elpa-packages` file in NonGNU ELPA: While it was removed from that file, it was never actually removed from NonGNU ELPA itself (because of a missing feature in `elpa-admin.el` which made it unable to remove a package from the `archive-contents`), so this doesn't make much difference in practice. But the problem in `elpa-admin.el` file is about to be fixed, and in the mean time the `hcel` package was added to GNU ELPA, and it uses `haskell-mode` to highlight its code, so we'd rather not remove `haskell-mode` from NonGNU ELPA any more. Is the version on NonGNU ELPA up to date with the latest changes of the MELPA one?

If you mean regular, rolling-release MELPA, then no. It is pinned to the latest release, which is apparently 17.2. Until the issue mentioned in this thread is fixed, this will also mean that the package won't be auto-updatable.

Answer 15 · 2022-11-02T07:29:08.000Z

If you mean regular, rolling-release MELPA, then no. It is pinned to the latest release, which is apparently 17.2. Until the issue mentioned in this thread is fixed, this will also mean that the package won't be auto-updatable.

I see, thanks for the explanation. The issue seems easily solvable, so fingers crossed. :)

Answer 16 · 2022-11-02T07:37:08.000Z

manuel-uberti ***@***.***> writes:

> If you mean regular, rolling-release MELPA, then no. It is pinned to the latest release, which is apparently 17.2. Until the issue mentioned in this thread is fixed, this will also mean that the package won't be auto-updatable. I see, thanks for the explanation. The issue seems easily solvable, so fingers crossed. :)

Yes, as I have said before, all it should involve is adding a non-0 "Version" header.

Answer 17 · 2023-03-24T10:32:32.000Z

This issue should be resolvable just like nex3/haml-mode#40.

Answer 18 · 2023-08-02T05:50:22.000Z

@purcell Sorry to periodically bother you with this, but any chance it can be moved forward?

Answer 19 · 2023-08-04T06:43:11.000Z

Version headers have just been bumped, and when I make future releases I'll bump them again. In the interim, my understanding is that I can just leave the "stable" version number in place unchanged and further commits in master won't cause re-builds in NonGNU ELPA, right? What are authors typically doing in this case in practice — bumping to a subsequent 14.4-git pre-release, or leaving the last stable version?

Answer 20 · 2023-08-04T06:51:17.000Z

Steve Purcell ***@***.***> writes:

Version headers have just been bumped, and when I make future releases I'll bump them again. In the interim, my understanding is that I can just leave the "stable" version number in place unchanged and further commits in `master` won't cause re-builds in NonGNU ELPA, right? What are authors typically doing in this case in practice — bumping to a subsequent `14.4-git` pre-release, or leaving the last stable version?

Yes, the next commit that bumps the version tag will be used to create the next release tarball. Basically, just bump the version tag in those commits you would tag as stable for MELPA Stable. Thanks!

Answer 21 · 2023-08-04T07:08:56.000Z

@purcell Fantastic Steve, thanks a lot for this.

Answer 22 · 2023-08-04T08:02:36.000Z

Thanks folks.

Answer 23 · 2023-08-04T08:08:54.000Z

Btw, I've done the same in a handful of my own popular repos:

exec-path-from-shell (requested here)
envrc (and inheritenv)
page-break-lines
reformatter (requested here and also discussed with @monnier)
package-lint

I won't personally have time to pursue getting any of those into NonGNU ELPA in the near future but if anyone else would like to, they can feel free.

Answer 24 · 2023-08-04T08:16:05.000Z

(Or just ELPA if appropriate.)

Answer 25 · 2023-08-04T17:40:41.000Z

I think adding exec-path-from-shell and package-lint has been requested, so I'll take a look at those first.

(Or just ELPA if appropriate.)

Do you know if all the significant contributors have signed the FSF CA?

Answer 26 · 2023-08-04T18:27:36.000Z

Uh, I might have been to quick to change things on NonGNU ELPA's end, the package still doesn't appear to have any version header. That would require a change like this

diff --git a/haskell-mode.el b/haskell-mode.el
index 0930680fb8..05707bcdc9 100644
--- a/haskell-mode.el
+++ b/haskell-mode.el
@@ -11,6 +11,7 @@
 ;;          2001-2002 Reuben Thomas (>=v1.4)
 ;;          2003      Dave Love <fx@gnu.org>
 ;;          2016      Arthur Fayzrakhmanov
+;; Version: 17.3
 ;; Keywords: faces files Haskell
 ;; URL: https://github.com/haskell/haskell-mode

Also, I just noticed that the Authors header has a very unconventional form that appears to displease describe-package. Would you be open to a patch that would standardize the header, resolving this issue for older versions of Emacs?

Answer 27 · 2023-08-04T18:42:31.000Z

I think adding exec-path-from-shell and package-lint has been requested, so I'll take a look at those first.
...
Do you know if all the significant contributors have signed the FSF CA?

For haskell-mode I doubt it. For package-lint and exec-path-from-shell, it's likely but I can't easily confirm it. Fine for things to go into NonGNU ELPA, but I think that for reformatter specifically there was a desire to have it in ELPA because a number of other packages depend on it, and I think I'm the only significant contributor there.

Uh, I might have been to quick to change things on NonGNU ELPA's end, the package still doesn't appear to have any version header.

The version number is in the -pkg.el file, which is the standard place to put such metadata for multi-file packages, so it'd be a pity if it had to be copied into a particular .el file as well. But obviously possible if there's no alternative. In MELPA over the last 10 years we've let authors put their metadata either in such a file or the headers of the <package-name>.el file, preferring the former if present.

Also, I just noticed that the Authors header has a very unconventional form that appears to displease describe-package. Would you be open to a patch that would standardize the header, resolving this issue for older versions of Emacs?

Yes, certainly.

Answer 28 · 2023-08-05T07:43:51.000Z

Steve Purcell ***@***.***> writes:

> I think adding exec-path-from-shell and package-lint has been > requested, so I'll take a look at those first. > ... > Do you know if all the significant contributors have signed the FSF CA? For `haskell-mode` I doubt it. For `package-lint` and `exec-path-from-shell`, it's likely but I can't easily confirm it. Fine for things to go into NonGNU ELPA, but I think that for `reformatter` specifically there was a desire to have it in ELPA because a number of other packages depend on it, and I think I'm the only significant contributor there.

I can try and take and find it out for myself.

> Uh, I might have been to quick to change things on NonGNU ELPA's > end, the package still doesn't appear to have any version header. The version number is in the `-pkg.el` file, which is the standard place to put such metadata for multi-file packages, so it'd be a pity if it had to be copied into a particular `.el` file as well. But obviously possible if there's no alternative. In MELPA over the last 10 years we've let authors put their metadata either in such a file _or_ the headers of the `<package-name>.el` file, preferring the former if present.

I cannot comment on that, the manual only says that the file has to be present for multi-file archives. In the case of GNU and NonGNU ELPA users don't have maintain these administrative files themselves, since they are automatically generated from the package header. Package-vc has the same assumption, btw, and both overwrite the -pkg.el file, so this is a more general problem than just here. That being said, I had been using haskell-mode via a package-vc installation and it seemed to have no issues with the aforementioned fact.

…

> Also, I just noticed that the Authors header has a very > unconventional form that appears to displease > describe-package. Would you be open to a patch that would > standardize the header, resolving this issue for older versions of > Emacs?

Answer 29 · 2023-08-05T08:22:34.000Z

MELPA also generates the -pkg.el file for multi-file packages, but only if it isn't there already. When present, it's used as-is, and considered to be the authoritative source of metadata. The logic for this is that technically you could have a package called foo-things containing foo-blah.el, foo-bloop.el and foo-things-pkg.el, with no foo-things.el at all. Not recommended, certainly, but possible. There are probably a couple of MELPA packages with that shape, though it would be rare.

Answer 30 · 2023-08-05T16:14:48.000Z

Steve Purcell ***@***.***> writes:

MELPA also generates the `-pkg.el` file for multi-file packages, but only if it isn't there already. When present, it's used as-is, and considered to be the authoritative source of metadata. The logic for this is that technically you could have a package called `foo-things` containing `foo-blah.el`, `foo-bloop.el` and `foo-things-pkg.el`, with no `foo-things.el` at all. Not recommended, certainly, but possible. There are probably a couple of MELPA packages with that shape, though it would be rare.

As far as I understand the issue, NonGNU ELPA would handle this by having to set a main file in the package specification, so I don't see why having a custom -pkg.el file is necessary.

Answer 31 · 2023-08-05T23:37:03.000Z

I cannot comment on that, the manual only says that the file has to be present for multi-file archives.

That describes the tarballs distributed by ELPA archives. But that does not apply to the repositories from which various scripts build the tarballs. Both Melpa and (Non)GNU ELPA build the `<pkg>-pkg.el` from the `<pkg>.el` headers so there is no need for duplication: just don't put any `<pkg>-pkg.el` in your repository.

Answer 32 · 2023-08-06T10:53:03.000Z

just don't put any <pkg>-pkg.el in your repository

Mostly agree, I wouldn't have put this here myself, and I'll remove it in favour of putting metadata in haskell-mode.el. I'll fix up the Author header at the same time.

Answer 33 · 2023-08-06T11:08:11.000Z

Done, and released as 17.4.