-
Notifications
You must be signed in to change notification settings - Fork 339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Distributing haskell-mode on NonGNU ELPA #1755
Comments
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 |
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. |
I understand your complaint, and if you wish it can be removed for the time being, or at least until others weigh in. |
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. |
Sorry for the delay, but the package has been removed now: https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/?id=6f642491e2cd5007c06c3d1ca2c11315185459b8. |
Thanks, appreciated. Let's leave this issue open to record the wish. |
No problem! I hope that it will be possible to install |
Has there been any progress on this issue? |
Friendly ping to know the status of this. :) |
To my knowledge, all that has to be done is to add a Version header. |
ping @purcell? |
Pi..ing? |
FWIW, I just re-added |
Is the version on NonGNU ELPA up to date with the latest changes of the MELPA one? |
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.
|
I see, thanks for the explanation. The issue seems easily solvable, so fingers crossed. :) |
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.
|
This issue should be resolvable just like nex3/haml-mode#40. |
@purcell Sorry to periodically bother you with this, but any chance it can be moved forward? |
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 |
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!
|
@purcell Fantastic Steve, thanks a lot for this. |
Thanks folks. |
Btw, I've done the same in a handful of my own popular repos:
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. |
(Or just ELPA if appropriate.) |
I think adding
Do you know if all the significant contributors have signed the FSF CA? |
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
Also, I just noticed that the |
For
The version number is in the
Yes, certainly. |
The version tag got bumped, and will be bumped in the future, so we can revert back to the default tracking of upstream updates, without manually pinning a specific version. [0] haskell/haskell-mode#1755 (comment)
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?
|
MELPA also generates the |
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.
|
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.
|
Mostly agree, I wouldn't have put this here myself, and I'll remove it in favour of putting metadata in |
Move package metadata to haskell-mode.el (see #1755)
Done, and released as 17.4. |
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.The text was updated successfully, but these errors were encountered: