emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs Package Management


From: Lennart Borgman
Subject: Re: Emacs Package Management
Date: Mon, 28 Sep 2009 23:48:36 +0200

On Mon, Sep 28, 2009 at 11:13 PM, Phil Hagelberg <address@hidden> wrote:
> Stefan Monnier <address@hidden> writes:
>
>> For the FSF-hosted repository of packages, I'd want all the packages
>> to be version controlled, so the "submit-package" would be nothing else
>> than "bzr commit" (but yes, some extra code would need to be written to
>> automatically build a tarball out of the newly committed code, ...).
>>
>>> Yes, this is something that package.el provides.  One thing that would
>>> be nice is to have Emacs also advertise the packages it provides -- that
>>
>> Indeed, we'd of course want that, if/once we provide such
>> a package system.  But that should be easy.
>
> It seems like though there are a few questions remaining about policies
> for submissions, there's a general consensus that Emacs should get a
> packaging system, probably based on package.el with some enhancements
> for submitting projects.
>
> I'd like to start brainstorming as to what this would look like.
>
> One way to do it would be to have every package register as a Savannah
> project, and have some kind of operation (probably implemented as an
> elisp function) that could produce the static files that package.el
> consumes and place them in a publicly accessible http-served
> directory. Making package releases correspond with VCS tags would
> simplify things, so with some kind of post-commit hooks Savannah could
> run this function whenever a tag is updated in the project.
>
> This would require very few changes to package.el. Writing such a
> function should not be difficult. The only question is how easy it would
> be to get Savannah to run it at the right time.
>
> Thoughts?

I think the way to go is to use a source code management system.
However I wonder if it would not be better with one project. That
would allow some structure to it.

The drawback is that some management have to be done and maybe it
looses the "everyone" can put something there thing then.

Perhaps structure can be combined with this somewhere else? Maybe as a
separate project that is a layer between the package system and the
package projects?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]