With #86, there is a problem because for single file packages, specifying a path such as modules/starter-kit-bindings.el work fine because starter-kit-bindings.el is just one file and so that file gets copied into the root path. However, with the proposed erlang package, there are multiple files and since the entire tree gets copied, the paths within the tar file include the parent directories.

I'm not sure what the solution is here, but maybe we need a "basedir" property for recipes. Will wait to let people chime in on this.

Current recipe of rsense is install only client, so that it can't use without copy server script manually.
It is easy to add server script to recipe, but we should set customize variable to work rsense right.
http://cx4a.org/software/rsense/manual.html#Install_Emacs_Extension

Is there any way to set this variable when I install this package?

To encourage contributions, we need a short guide for contributors; which file to edit, which options the recipes support, how to test-build a recipe etc.

I am wanting to get ESS in the repo but the package isn't that "package.el friendly". Right now there is a file ess-site.el in the lisp directory of the package that needs to be required after installed. There aren't pre-defined autoloads for the package and so I am not really sure where to go. I think I need to file a bug with the ESS people and/or see how it's done in main repository. I'll have a look. I don't know how much "special" code we want to put into MELPA just to handle one package. But it's an important package. Maybe it's better for this package just to use a marmalade / elpa version.

I think that :repo can stand for a URL or even a specific mapping such as with github?

I found it weird that they were different, and I can't remember if we talked about this?

buildpkg script uses shebang #!/usr/bin/env emacs --script where emacs --script is treated as single argument on linux systems (tested on Arch). According to http://en.wikipedia.org/wiki/Shebang_(Unix):

Another portability problem is the interpretation of the command arguments. Some systems, including Linux, do not split up the arguments[14]; for example, when running the script with the first line like,

!/usr/bin/env python -c

That is, python -c will be passed as one argument to /usr/bin/env, rather than two arguments. Cygwin also behaves this way.

As a result:

ineu@ineu melpa % LANG= ./buildpkg
/usr/bin/env: emacs --script: No such file or directory

This is somewhat bikeshedding, but it would be helpful for the recipes were all named foo.el so Emacs could recognize and apply the correct mode. Always nice not to have to make the extra effort of telling Emacs what mode to use :)

Hi,

package-build.el requires package.el, which is not included by default in Emacs < 24.

Adding it to the MELPA repo or adding a note inte the README is probably a good idea!

This may be an upsteam issue, but when trying to install the slime package, the slime-repl.el fails to compile (and load). Recompiling the file however seems to work.

I get the following error when I try to use dired on the recipes directory.

Wrong type argument: stringp, nil

Many el-get recipes (https://github.com/dimitri/el-get/tree/master/recipes) could be automatically translated into Melpa recipes, and doing so would immediately make Melpa more extensive and useful.

Here's an example el-get recipe file:

(:name auto-complete
       :website "http://cx4a.org/software/auto-complete/"
       :description "The most intelligent auto-completion extension."
       :type github
       :pkgname "m2ym/auto-complete"
       :depends (popup fuzzy)
       :load-path "."
       :post-init (progn
                    (require 'auto-complete)
                    (add-to-list 'ac-dictionary-directories
                                 (expand-file-name "dict"))
                    (require 'auto-complete-config)
                    (ac-config-default)))

I noticed the following error,

"Removing archive: (inliner . [(20120520) nil insert Tag for inline image of R graphics [source: github] single])"

"Removing archive: (helm-r . [(20120523) ((helm (20120517)) (ess (20120509))) helm-sources and some utilities for GNU R. [source: github] single])"

And the problem is that package-build-alist is setup to use package names out of the "recipes" directory which allows for capitalization of the package name. However, in pb/merge-package-info the name is getting downcased. And thus when the package gets added to pacage-build-archive-alist the car of each package is no longer consistent. I have removed the downcase in 6c46737

Please close this if it is OK, otherwise let us discuss why that is in there.

We have git://git.boinkor.net/slime.git as the repo for slime but it's been unresponsive today. Not sure where else we could go for this and I can't figure out where that url came from. Quick google search didn't turn up anything except for a CVS repo from common-lisp.net

I found when a package just has one file,then package build rename the file to repo-name file that descripted in recipe file.but in this case if repo-name is not same with the origin file name and the provide sentence argument ,then the package can't loaded by package.el.
so I found evil-surround package encountered this scene .repo-name is evil-surround,but file name is surround and has (provide 'surround) sentence in file. thus package.el download this package in melpa evil-surround.el to elpa fold.but can't be load because filename is no consistence with provide argument.

Hello,

When trying to install the volatile-highlights package, I get the following:

Contacting host: melpa.milkbox.net:80
package-handle-response: Error during download request: Not Found
Quit [2 times]
Mark set
Install package `volatile-highlights'? (y or n) y

nil

Contacting host: melpa.milkbox.net:80
package-handle-response: Error during download request: Not Found

Same is happening for yasnippet - but that's already been reported.

Cheers,

looks like http://www.pps.jussieu.fr/ is down. so vc-darcs is not building today. will wait until tomorrow but otherwise we should decide what to do with this package.

It would be good to let recipe contributors know in advance what guidelines we apply when deciding whether to add their package.

Some possible constraints:

• Upstream source must be stored in an authoritative SCM repo, or on the Emacswiki
• Must be actively developed, or not otherwise included in a different ELPA archive (see #64)
• ...

Consider #78, in which several packages are built from @bbatsov's prelude-modules repo. The git fetcher uses the timestamp of the last commit as the package timestamp, regardless of whether that commit touched the elisp being packaged, so all the prelude-* packages will get rebuilt if any file in that repo is touched.

We should instead determine the timestamp by looking at the timestamp of the most recent commit to touch the files matched by :files.

(This is a particularly big issue with packages like erlang-mode, which I am in the process of adding. The elisp for that lies deep within a huge repo of unrelated code, and so that package would certainly be rebuilt at least daily with the existing package-build code.)

If the source directory exists but the update fails, the package should still be built. Otherwise it doesn't show up in the package list.

Can't access melpa packages archive address(http://melpa.milkbox.net/packages/),response "403 Forbidden"

The shimbun recipe added in #176 uses the emacsmirror repo for w3m. However, there's a CVS repo available upstream according to http://emacs-w3m.namazu.org/#download.

If we added CVS support (probably limiting URLs to those using the :pserver: protocol) we would therefore find it easier in some cases to obtain source from the authoritative source repo.

The yasnippet package address (http://melpa.milkbox.net/packages/yasnippet-20120822.52.tar) will return 404 error.

Please add a recipe for ebib.

ebib is a powerful BibTeX database manager.

When a recipe specifies an upstream source with numeric tags (or perhaps branches), we can use that info to build stable packages.

package.el won't easily handle coexistence of stable and snapshot packages in the same package archive, since package-list-packages (currently) only shows the highest available version number of a package, and package.el provides no way to selectively install a version 1.4 instead of 20120406.

Renaming snapshot packages to add a -snapshot suffix is an option, but might wreak havoc with inter-package dependencies; foo-snapshot packages would not satisfy a dependency upon foo, for example, and so dependency names might need to be updated.

The alternative plan we've discussed is to provide two parallel archives, each with separate URLs and contents; one would contain snapshot packages, and the other would contain stable packages. In reality, though, many users would want to combine packages from both archives, and so machinery like that provided by melpa.el would be required in order to selectively install stable package versions when snapshots are also available.

On melpa.milkbox.net, the "fork me on github" link points to https://github.com/you instead of https://github.com/milkypostman/melpa/

There is:

https://github.com/emacsmirror/d-mode

but that is a fork of:

https://github.com/Emacs-D-Mode-Maintainers/Emacs-D-Mode.git

I noticed this because for some reason the working directory for d-mode got messed up.

i have several packages in a list, marked as obsolete. i can't delete them, because Emacs throws the following:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
file-name-directory(nil)
package-delete("yasnippet" "20120502")
#[nil "\301�@�A\"\207" [elt package-delete] 3]()
package-menu-execute()
call-interactively(package-menu-execute nil nil)

What could be the problem?

The package list at http://melpa.milkbox.net/ has certain non-word characters missing from the package descriptions, such as the apostrophe in:

A version of Chris Kempson s various Tomorrow themes

Additionally,

Major mode for editing LESS CSS files (lesscss org)

is displayed as

Major mode for editing LESS CSS files lesscss org

I haven't investigated the cause for this yet, but wanted to log it as a (minor) issue.

Packagers could start to add a Source packaging attribute to define the canonical source of the package, for example:

;;; elnode.el --- a simple emacs async HTTP server -*- lexical-binding: t -*-
;; Copyright (C) 2010  Nic Ferrier
;; Author: Nic Ferrier <[email protected]>
;; Maintainer: Nic Ferrier <[email protected]>
;; Created: 5th October 2010
;; Version: 0.9.2
;; Keywords: lisp, http, hypermedia
;; Package-Requires: ((fakir "0.0.3")(creole "0.8.1"))
;; Source: git://github.com/nicferrier/elnode.git

If package maintainers did this then MELPA would be able to scan Marmalade for new packages and pull their source into MELPA.

Hey,

MELPA seems nice. I hope I can find time to contribute it!

When I run:

./buildpkg yari

I get:

End of file during parsing

Any ideas!?

I added ein-pkg.el to my EIN package and try to build package locally. However, it seems that generated ein-pkg.el overwrites the existing one. Is this expected behavior?

% emacs-snapshot -Q --script ./buildpkg ein
[...]
% tar -Oxf packages/ein-20120703.tar ein-20120703/ein-pkg.el
(define-package "ein" "20120703" "No description available. [source: github]" 'nil)
% cat working/ein/lisp/ein-pkg.el
(define-package "ein"
  "0.1beta1"
  "Emacs IPython Notebook"
  '((websocket "0.9")))

In this code in readme:

(name
 :fetcher [git|github|bzr|hg|darcs|svn|wiki]
 [:url "<repo url>"]
 [:repo "github-user/repo-name"]
 [:files ("<file1>", ...)])

please change name to <name>, because at first look it is easy to forget that there is no function called "name" and instead there should be a name of a package. This is a minor issue, but for sum reason i stumbled several time upon this.

At least one package ends up with an empty description because the contents of its -pkg.el file is not simply a (define-package ...):

See https://github.com/emacs-helm/helm/blob/master/helm-pkg.el, which looks like the following:

;;; helm-pkg.el --- define helm for package.el
(eval-when-compile (require 'package))
(define-package "helm" "1.4.0"
  "Helm is an Emacs incremental and narrowing framework")

When we slurp in data files, we just take the first expression. If we could guarantee it would be safe, we could eval the pkg files and collect the package info defined there, but this isn't practical. Instead, pb/get-pkg-file-info should really search all the expressions in the pkg file, and extract arguments from the expression that is an invocation of define-package.

I just synced my fork to upstream and rebuild everything by running ./melpa, and I got:

*** Building html

146/151 packages built

Would it be a good idea for the 5 failing packages to get listed?

When i try to open directory recipes/ in Emacs either from Dired or through find-file, the error is thrown:

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("R" nil)
dired-sort-R-check(nil)
dired-sort-other(nil t)
dired-mode("~/labor/melpa/recipes/" "-al")
dired-internal-noselect("~/labor/melpa/recipes/" nil)
dired-noselect("~/labor/melpa/recipes/")
run-hook-with-args-until-success(dired-noselect "~/labor/melpa/recipes/")
find-file-noselect("/home/sindikat/labor/melpa/recipes/" nil nil)
ido-file-internal(raise-frame)
ido-find-file()
call-interactively(ido-find-file nil nil)

I tried it with both Ido-mode enabled and disabled. May be it is not melpa issue at all. What could it be?

I found evil recipe in recipes directory,but can't fint it in archive and package-list can't find it too.maybe lost it when gather pack?

I've kinda hot-patched the git reset stuff because some repositories don't specify a HEAD branch and thus have an ambiguous one (see gnuplot and popwin).

In e20c315 I've set it to default to master but I don't like this code (seems sloppy to me) and there has to be a better way?

I'm working with Pymacs author to make it compatible with ELPA and wanted to create a Melpa recipe for it. The problem is it uses some sort of preprocessing to update version in .el file, check for some compatibility problems and other minor stuff.

Do you plan on adding some sort of post-processing mechanisms? It can be similar to post-inst of el-get. In case of Pymacs it is essentially enough to run "make" in fetched directory of the package to create a cleared up .el file.

js2-mode is named js2-mode in the repository, but js3-mode is named js3. So I don't understand the difference. Just seems weird.

I tried M-x package-install RET slime, and I'm getting "Error during download request: Not Found". I can build it locally with ./buildpkg slime, but for whatever reason, it's not on the server.

These are my package-archives from describe-variable:

Its value is (("gnu" . "http://elpa.gnu.org/packages/")
("melpa" . "http://melpa.milkbox.net/packages/"))

Im using emacs-snapshot in Ubuntu 12.04.

Byte compilation and connecting produce cannot open load file: jabber-autoloads error.

Maybe because there is no jabber-autoloads in elpa/jabber folder? There is jabber-mode-autoloads there though

Right now the mediawiki package clones every time the package is built. This may be a bzr issue.

In the long term, having github serve the built packages would likely result in a more stable and maintenance-free experience for both @milkypostman and Melpa's users.

To achieve this, the build script could commit built packages to the gh-pages branch, and then push them up to github.

It would be worth trying this out (perhaps in a test repo) to determine whether there are any url timeout issues, since these are often seen when installing packages from upstream archives (see recommended workarounds for melpa itself).

What are the reasons to not use the internally marked version of packages? Perhaps this should be a recipe option.

Currently MELPA uses the commit date as the version number, with a resolution of days (i.e. 20120815). If the package is updated within the same day it is repackaged with the same version number. Now there are two different versions of the package with the same version number. package won't know to update between these.

A bigger concern to me: there's also the inconsistency with the same package hosted in other archives. For example, Marmalade lists smex as version 1.1.2 while MELPA lists it as version 20120812. If I want to list a dependency in my package I have to either decide which package archive I'm going to support or maintain multiple versions.

I understand one reason why the current method is desirable: package maintainers don't (and can't, and shouldn't) bump the version number with every commit, so there would still be version collisions. Some may never increment their version number.

Recipe option

Each method makes sense in different scenarios. The versioning method could be selected in the recipe (defaulting to commit),

(<package-name>
 ...
 [:versioning <commit|internal>])

Better commit date resolution

The commit version could have better resolution. Currently MELPA updates hourly, so YYYYMMDD.hh would make more sense as a version number.

bazaar is somewhat popular (albeit far less than git) for hosting Emacs related projects (probably because of Ubuntu's Launchpad and the fact that it's used by Emacs itself). It would be really nice if bazaar support were added to MELPA.

Since so many packages are developed on github it would be nice if it were treated a little bit specially in pkglist. In a Ruby Gemfile one can write either:

"some_gem", git: "https://github.com/user/repo"

or

"some_gem", github: "user/repo"

Maybe we can have a github fetcher as well :-)

The http://melpa.milkbox.net/packages/ URL is returning a 403 Forbidden error for me.