Split beancpunt.el into its own repository

[Daniele Nicolodi]

Hello,

I think it would be worthwhile to split beancount.el into its own
repository (maybe https://github.com/beancount/beancount.el or
https://github.com/beancount/beancount-mode) for it to be released
independently of beancount.

Martin, what do you think?

Cheers,
Dan

[Martin Blais]

Given its small size, a whole dedicated repo is a bit much, don't you think?

Always happy to take patches.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/194c402a-28ce-937c-9339-066517256ebc%40grinta.net.

[Stefano Zacchiroli]

On Wed, Oct 07, 2020 at 06:20:04AM -0400, Martin Blais wrote:
> Given its small size, a whole dedicated repo is a bit much, don't you think?
> Always happy to take patches.

The main point is release independence. I'd love to be able to receive
beancount.el releases (e.g., via MELPA or similar repos) without having
to wait for a Beancount release. In fact, as a user, I don't see why
the release processes of the two should be tightly coupled at all.

git repositories are cheap.

Cheers
--
Stefano Zacchiroli . za...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

[Martin Blais]

Does a MELPA (or other) release have to be tied to a beancount tag?

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20201007103846.ln2sbaekba4nsnck%40upsilon.cc.

[Martin Blais]

I mean I don't care that much, I can create a repo in the org and move it there (and open up maintainers list), but it seems to me one could just as well pick it up from HEAD of v2 or master. Just trying to understand.

(There's a lot more that could be done on emacs support for beancount. Especially around thing-at-point functionality)

[Stefano Zacchiroli]

On Wed, Oct 07, 2020 at 06:50:38AM -0400, Martin Blais wrote:
> I mean I don't care that much, I can create a repo in the org and move it
> there (and open up maintainers list), but it seems to me one could just as
> well pick it up from HEAD of v2 or master. Just trying to understand.

Yeah, I'm sure you can piggy back a release process for beancount.el
alone on top of the current beancount repo. But you lose clarity, e.g.,
it becomes cumbersome to bump the beancount.el version without bumping
the beancount one. You can work around that with, I guess, a dedicated
namespace in tag names, but meh...

[Daniele Nicolodi]

On 07/10/2020 12:47, Martin Blais wrote:
> Does a MELPA (or other) release have to be tied to a beancount tag?

I am not MELPA expert, but MELPA in its classic form does not really
have the concept of releases. In the easiest form, packages are picked
up from a git repository. What can easily be specified is probably a
specific branch.

Cheers,
Dan

[Daniele Nicolodi]

On 07/10/2020 12:20, Martin Blais wrote:
> Given its small size, a whole dedicated repo is a bit much, don't you think?

It is going to be a small repo :-)

As Stefano pointed out, having some decoupling between beancount and the
emacs mode will make managing releases easier. The presence of two
active branches in the beancount git repository is also going to cause
some confusion regarding which one is the canonical source for the emacs
mode source code. And I would like to avoid to have to merge every patch
to beancount.el twice.

I think the advantages clearly outweigh the disadvantages (actually, I
don't see any disadvantage in splitting the repositories).

Cheers,
Dan

[Martin Blais]

Alright, in the spirit of letting others take space, let's do it.

I've been more or less rubberstamping PRs on the mode anyhow.

You'll probably rejoice at the GLPv3 I set it up with.

New repo:

  https://github.com/beancount/beancount-mode

To packagers: I also removed Emacs support from both beancount@v2 and beancount@master, in the interest of having a single copy. (BTW I have a few experimental minor things in etc/emacsrc, around invoking a journal for the account at point. I'll probably migrate those eventually.)

I put the code under a /emacs subdirectory, so that if this eventually evolves to contain support for other editors, it'll be easy to create just another directory at the root.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/b8d0a9e3-2fee-5370-fa94-dbd78f7541c8%40grinta.net.

[Daniele Nicolodi]

On 11/10/2020 06:02, Martin Blais wrote:
> Alright, in the spirit of letting others take space, let's do it.

Thank you.

> You'll probably rejoice at the GLPv3 I set it up with.

I was perfectly happy with the GPLv2 license.

Actually, beancount is distributed under GPLv2 only, thus relicensing
this code under the GPLv3 would not be possible to do without consent
from all authors.

> New repo:
>
>   https://github.com/beancount/beancount-mode
>
> To packagers: I also removed Emacs support from both beancount@v2 and
> beancount@master, in the interest of having a single copy. (BTW I have a
> few experimental minor things in etc/emacsrc, around invoking a journal
> for the account at point. I'll probably migrate those eventually.)
>
> I put the code under a /emacs subdirectory, so that if this eventually
> evolves to contain support for other editors, it'll be easy to create
> just another directory at the root.

I think this is counter to the reasons of splitting the emacs support
into its own repository. Support for other editors already lives in
dedicated repositories, and I don't see the reason to centralize the
code here.

I would also like to preserve the history of the files imported into the
new repository. I am sure there is a git incantation to do this.

Do you mind if I prepare a repository (with only the emacs mode,
preserving its history) to be force pushed in place of the current one?

Thank you.

Best,
Daniele

[Stefano Zacchiroli]

On Sun, Oct 11, 2020 at 09:53:56AM +0200, Daniele Nicolodi wrote:
> I would also like to preserve the history of the files imported into the
> new repository. I am sure there is a git incantation to do this.

Yeah, that would be `git filter-branch` with the `--tree-filter` for
selecting only the `emacs/` dir, whose content you can them move out of
that dir in a final commit. I've (unfortunately for me) had to often
merge/separate git repos often, so feel free to ping me offline if you
need a hand with that.

[Stefano Zacchiroli]

On Sun, Oct 11, 2020 at 11:06:23AM +0200, Stefano Zacchiroli wrote:
> Yeah, that would be `git filter-branch` with the `--tree-filter` for

s/tree-filter/subdirectory-filter/

(which is newer and better)

[Daniele Nicolodi]

On 11/10/2020 11:07, Stefano Zacchiroli wrote:
> On Sun, Oct 11, 2020 at 11:06:23AM +0200, Stefano Zacchiroli wrote:
>> Yeah, that would be `git filter-branch` with the `--tree-filter` for
>
> s/tree-filter/subdirectory-filter/
>
> (which is newer and better)

I discovered git-fiter-repo that is easier to work with. I am refining
the last details. I should have a clean repository ready in a little while.

Cheers,
Dan

[Daniele Nicolodi]

The repository is ready here [*]:

https://github.com/dnicolodi/beancount-mode

with the history preserved, a IMHO better structure, and a README with a
first attempt at documenting beancount-mode. The documentation should
probably be a more structured, but what there is covers the basics.

Martin, can you please consider replacing the repository you created
with this one?

Thank you.

Cheers,
Dan


[*] if anyone is curios, this has been obtained with these commands:

# clone
git clone --branch v2 https://github.com/beancount/beancount.git
cd beancount

# reset repository to before the removal
git reset --hard ff1139b2ed3face9befb7a5bc2c7de7096024032

# filter
git filter-repo --path editors/emacs/ \
--path etc/emacsrc \
--path-rename editors/emacs/:

# set remote
git remote add origin g...@github.com:dnicolodi/beancount-mode.git

# rename trunk branch
git branch -M main

# push
git push -u origin main

[CG Evans]

Thank you: being able to install beancount-mode via modern methods is
quite convenient, and seems like a considerable advantage of having a
separate repository for emacs.  I'm using

(straight-use-package '(beancount-mode :type git :host github :repo
"dnicolodi/beancount-mode" :branch main))

which seems to work well.

Kind regards,
Constantine

[Martin Blais]

Thanks Daniele,

I replaced my repo with your that has the history.

I always bothered doing this for my mercurial repos but didn't feel it was worthwhile for this one. Thanks for doing it.

I added the GPL v2 license to it.

Now... in doing this I went a little too fast... I deleted the repository I had created (which is fine), but I had already transferred all the Emacs tickets to it and deleting the old repo wiped them too... so they tickets gone. I think I had transferred 4 or 5 of them. I'll try to recreate some of them from email notifications.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/97952478-0949-b950-0b8f-c134448994df%40grinta.net.

[James Cook]

I notice beancount.el itself says "either version 3 of the License, or
...", both in the new repos and in the main beancount repo (before it
was deleted).

It looks like that text was added in
https://github.com/beancount/beancount/commit/6275a6a385a365065918d3c99c4410fa77aea4ed

So maybe it's actually GPLv2 that you can't licence beancount.el
under. I haven't checked the history of the file up to the point,
though; I don't know whe contributed to it before licence text was
added.

James

> To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPcaBtOkV%3DcfkcBOSLBuSUnRDufFUOhvZ5-ugSyTFnWdg%40mail.gmail.com.