Make headers conform to package.el requirements #21

Merged
merged 1 commit into from Mar 15, 2013

Projects

None yet

2 participants

@purcell
Contributor
purcell commented Mar 15, 2013

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.

@purcell purcell 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.
d7df931
@purcell purcell referenced this pull request in melpa/melpa Mar 15, 2013
Merged

adding recipe for scion #585

@nominolo
Owner

The patch looks good.

I have some more general questions about the process of being included in MELPA:

  1. Which version does it bundle and how is it updated? I.e., do you need a release, or do you just point to master/stable branch?
  2. What about the additional bits like the Haskell part? If the user has to install that separately, how do we make sure the same versions are matched up?

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.

@purcell
Contributor
purcell commented Mar 15, 2013

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?

-Steve

@nominolo
Owner

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.

@nominolo nominolo merged commit 99b4589 into nominolo:master Mar 15, 2013
@purcell
Contributor
purcell commented Mar 15, 2013

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment