Does Elpa welcome themes? Or should those stay in Melpa?

Does Elpa welcome themes? Or should those stay in Melpa?

[M]

Hi all,

New to the mailing list and Savannah/GNU - hoping this is the right
place to ask this (I incorrectly asked Savannah-users last night -
hoping for better luck today).

If there is a more specific Elpa related list, please let me know and/or
disregard this.

I recently finished the copyright assignment docs with the FSF so I can
be a part of the GNU Emacs group.

My original intent/interest was to add my color theme found here:
https://github.com/ahungry/color-theme-ahungry

Into Elpa (I also submitted it to Melpa tonight).

I notice that there aren't any other themes in Elpa (or if so, I'm
missing them).

Is this primarily due to reluctance in assigning copyright to FSF by
theme maintainers or a preference by Elpa to keep them out of the base Elpa/Emacs?

On a related note, if I want to continue hosting the code at the current URL and
also clone it into the Elpa repository, would it be better to do it as
an "external" type or a "subtree" type?

Thanks in advance,
-Matt

-- 
Matthew Carter
m@ahungry.com

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Stefan Monnier]

> I notice that there aren't any other themes in Elpa (or if so, I'm
> missing them).

Indeed I think there aren't any currently.

> Is this primarily due to reluctance in assigning copyright to FSF by
> theme maintainers or a preference by Elpa to keep them out of the base
> Elpa/Emacs?

At least it's not because we don't want them in GNU ELPA.

> On a related note, if I want to continue hosting the code at the
> current URL and also clone it into the Elpa repository, would it be
> better to do it as an "external" type or a "subtree" type?

If you want my preference, for small packages, I prefer
the "subtree" kind, but it's your call.


        Stefan

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Artur Malabarba]

> Hi all,
Hi

> New to the mailing list and Savannah/GNU - hoping this is the right
> place to ask this (I incorrectly asked Savannah-users last night -
> hoping for better luck today).
>
> If there is a more specific Elpa related list, please let me know and/or
> disregard this.
I believe this is the right place.
Just allow me to be slightly pedantic here and say "Elpa" is a generic
name for package archives. You're actually referring to GNU Elpa
(which I'll just call Gelpa below, 'cause that's cute). I'm not really
correcting you, it's just something to be aware as other people in
this list might use that distinction.

> I notice that there aren't any other themes in Elpa (or if so, I'm
> missing them).
>
> Is this primarily due to reluctance in assigning copyright to FSF by
> theme maintainers or a preference by Elpa to keep them out of the base Elpa/Emacs?
I'm not aware of any such preference, but Stefan can probably be of
more help here.

> On a related note, if I want to continue hosting the code at the current URL and
> also clone it into the Elpa repository, would it be better to do it as
> an "external" type or a "subtree" type?
I use a subtree for Names, and it's suiting me well. I can show you
the exact commands I use (not at my linux box right now), but the
basic procedure is the following:
1. Create the package's directory
2. Add your repo as a remote
3. Do a subtree merge to put the package in its directory, and repeat
it whenever you want to update the Gelpa version.

This is the nicest approach I found. Every commit form your remote
will be mirrored on Gelpa's git repo, and there will be a single extra
merge commit whenever you do the merge.
The only slight disadvantage is that your very first merge will pull
every commit since you started the repo, so you'll kind of flood
Gelpa's commit list when you first add the package (if your repo was
relatively old).

The other option is to do development straight on Gelpa. There's
little reason to push the package to other elpas if it's on Gelpa,
which reduces the need for a Github repo. It's what I do on
`let-alist', but it's certainly not suited for all packages.

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Matthew Carter]

Hi all,

I've merged my package into my local GNU Elpa git repository as a
subtree, however I notice I'm unable to git push upstream.

When signing into Savannah, I see I'm still pending to join the emacs
group - my copyright assignment for GNU Emacs went through a week or two ago.

Are there any other things I need to do to gain developer access to the
GNU Elpa repository and push my package
(https://github.com/ahungry/color-theme-ahungry)?

Also - I have two .el files in the repository currently (never to be
used in tandem) - one is a fallback for users with emacs less than 24.x
to be used with the color-theme package, the other (ahungry-theme.el) is
the main theme to be used with load-theme.

Is it a problem to leave both in the repository (and subtree merge under
elpa/packages/ahungry-theme) or should I remove the fallback one and
keep it separate entirely (I guess it would not work alone in the base
GNU Elpa if a user didn't have color-theme installed like the load-theme
would)?

Thanks,
-Matt

On Fri, Jan 16, 2015 at 06:27:57PM -0500, Stefan Monnier wrote:
> > I notice that there aren't any other themes in Elpa (or if so, I'm
> > missing them).
> 
> Indeed I think there aren't any currently.
> 
> > Is this primarily due to reluctance in assigning copyright to FSF by
> > theme maintainers or a preference by Elpa to keep them out of the base
> > Elpa/Emacs?
> 
> At least it's not because we don't want them in GNU ELPA.
> 
> > On a related note, if I want to continue hosting the code at the
> > current URL and also clone it into the Elpa repository, would it be
> > better to do it as an "external" type or a "subtree" type?
> 
> If you want my preference, for small packages, I prefer
> the "subtree" kind, but it's your call.
> 
> 
>         Stefan

-- 
Matthew Carter
m@ahungry.com

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Stefan Monnier]

> Are there any other things I need to do to gain developer access to the
> GNU Elpa repository and push my package
> (https://github.com/ahungry/color-theme-ahungry)?

This should be solved now.

> Also - I have two .el files in the repository currently (never to be
> used in tandem) - one is a fallback for users with emacs less than 24.x
> to be used with the color-theme package, the other (ahungry-theme.el) is
> the main theme to be used with load-theme.
> Is it a problem to leave both in the repository

A package can have several files, so that shouldn't be a problem.


        Stefan

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Matthew Carter]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Are there any other things I need to do to gain developer access to the
>> GNU Elpa repository and push my package
>> (https://github.com/ahungry/color-theme-ahungry)?
>
> This should be solved now.
>
>> Also - I have two .el files in the repository currently (never to be
>> used in tandem) - one is a fallback for users with emacs less than 24.x
>> to be used with the color-theme package, the other (ahungry-theme.el) is
>> the main theme to be used with load-theme.
>> Is it a problem to leave both in the repository
>
> A package can have several files, so that shouldn't be a problem.
>
>
>         Stefan
>

Thanks Stefan.

Stefan (or anyone else) - for the subtree, should I add it via read-tree as
described here:

http://www.git-scm.com/book/en/v1/Git-Tools-Subtree-Merging

to allow updates via 'git merge -s subtree ahungry-theme-branch'
(similar to what the GNU Elpa README mentions), or add
it directly with the subtree command (it looks like hydra recently used
this for adding).  In my case:

git subtree add --prefix packages/ahungry-theme \
  https://github.com/ahungry/color-theme-ahungry master --squash

And subsequent pulls via:

git subtree pull --prefix packages/ahungry-theme \
  https://github.com/ahungry/color-theme-ahungry master --squash

It seems like the git subtree commands are a little more direct.  Were
they unavailable when the other process was used?

Is there a reason to use git read-tree and keeping the remote in a local
branch under GNU Elpa that I'm missing?

Thanks,
-Matt

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Artur Malabarba]

> git subtree add --prefix packages/ahungry-theme \
>   https://github.com/ahungry/color-theme-ahungry master --squash
>
> And subsequent pulls via:
>
> git subtree pull --prefix packages/ahungry-theme \
>   https://github.com/ahungry/color-theme-ahungry master --squash

This is what I do, but without the --squash. The squash hides all
history for me, which is not what I want. It's ok for your package's
history to be part of Gelpa's history.

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Matthew Carter]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> git subtree add --prefix packages/ahungry-theme \
>>   https://github.com/ahungry/color-theme-ahungry master --squash
>>
>> And subsequent pulls via:
>>
>> git subtree pull --prefix packages/ahungry-theme \
>>   https://github.com/ahungry/color-theme-ahungry master --squash
>
> This is what I do, but without the --squash. The squash hides all
> history for me, which is not what I want. It's ok for your package's
> history to be part of Gelpa's history.
>

Hi all,

I pushed ahungry-theme.el into GNU Elpa (Gelpa) as a subtree with the
squash option, as at one point I had some sample images of the theme in
the github repo, instead of hosted outside of it, and I didn't want to
fatten up the git history with old unused blob data (they are hosted
externally now and only referred to in the README.md).

Please let me know if there are any issues with the commit, and thanks
for letting me contribute to GNU Emacs/ELPA.

-- 
Matthew Carter (m@ahungry.com)
http://ahungry.com

Re: Does Elpa welcome themes? Or should those stay in Melpa?

[Stefan Monnier]

> to allow updates via 'git merge -s subtree ahungry-theme-branch'

I've used "git merge -s subtree ..." myself and that's what I'd
recommend.  But you can use whatever suits you: you'll be the one who
needs to keep the elpa.git code up-to-date.

> Is there a reason to use git read-tree and keeping the remote in a local
> branch under GNU Elpa that I'm missing?

I don't see a reason to keep the remote in a local branch, tho I'm not
sure what "local branch" means here.


        Stefan