We'd like to add a scion package to MELPA, but the headers (and footer line) are not package.el-compliant, so an installable package cannot be built.
This commit reformats the header slightly, and adds the required trailing "ends here" line.
Make headers conform to package.el requirements
We'd like to add a scion package to MELPA, but the headers
(and footer line) are not package.el-compliant, so an installable
package cannot be built.
This commit reformats the header slightly, and adds the required
trailing "ends here" line.
The patch looks good.
I have some more general questions about the process of being included in MELPA:
One reason I'm asking this is that this version of Scion is fairly old. I'm planning to revive it in a few months, but I think the current version is of questionable use.
MELPA builds snapshot packages directly from the upstream github repo, ie. this repo. The process is unattended, so future commits here will result in updated packages on MELPA.
Since a MELPA user submitted a request to add Scion, I'm assuming that the current version is at least of use to some people, but I could be completely wrong.
Regarding the Haskell part, it's not unusual for us to include helper scripts in MELPA packages, but that's not really practical in Scion's case. I guess a user would have to separately download the Scion source and cabal install it. The MELPA package would at least help him get a recent scion.el into his Emacs.
Will it eventually be practical to distribute scion via Hackage, or will it always need to be built locally?
I hope to have it eventually be distributed via Hackage (again). If MELPA makes it easy to select which version to use (so that it matches the installed Hackage version), then using MELPA as an easy way to setup the Emacs side of things would be fine.
Right now, the focus of MELPA is on snapshot packages, but a goal is also to be able to build stable release packages by inspecting repository version tags. Marmalade is an alternative package repository suited to publishing stable packages, but it has no automatic packaging mechanism, and a clunky user / ownership model.
Thanks for merging!