emacs-devel
[Top][All Lists]
Advanced

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

Re: [nongnu] main f4166f428a: * elpa-packages (emacsql): New package.


From: Jonas Bernoulli
Subject: Re: [nongnu] main f4166f428a: * elpa-packages (emacsql): New package.
Date: Sat, 17 Dec 2022 03:01:49 +0100

>> Agreed.  Let's see what Jonas thinks about the plan I proposed.
>
> I am super busy and would like to delay thinking about this and working
> on it until next year.
>
> I might actually come to the conclusion that not splitting up the
> package is the right way to go in this case.  Or the backends that--to
> the best of my knowledge--nobody uses (all the non-sqlite backends),
> could be moved to separate repositories.  Eventually -sqlite-builtin
> will be the default backend, but we still need -sqlite-module, for older
> Emacs releases.  I intend to deprecate the original -sqlite backend
> (which uses a custom executable) in a few months, and I intend to then
> remove it from the repository (to get rid of the tracked sqlite.c), but
> keep it alive in a separate repository for a while.

My current medium term plan is to distribute emacsql.el,
emacsql-sqlite-builtin.el and emacsql-sqlite-module.el as a single
package and stop maintaining and distributing all the other backends.

Packages that use "Emacsql" all want to use sqlite, but it does not
matter to them which sqlite backend is used, which very soon will depend
on what Emacs version is used. (But unfortunately, dependants need some
boilerplate to support the various backends and so that they can leave
the choice up to the user.  Maybe something can be done about that
boilerplate.  Distributing these three libraries together would probably
help with that.)

The reason I don't want to include emacsql-sqlite.el is that I want to
move it out of the repository fairly soon (along with all the c code),
once the two replacements have proven themselves in production.  Since
this library is currently being distributed separately, we might just as
well keep doing that.  If we make it part of emacsql now, then it would
only remain there for a while, and then in about a month or two it would
be split into a separate package again.

The non-sqlite backends are not really used by anyone.  I think not
distributing them at all, at least for a while, would be a good way to
find out if there is anybody who uses them.  I don't really want to
maintain these backends and would prefer if someone else, who actually
uses them, maintained them, in a separate repository.  So again, if we
include them in emacsql now, that is something that might be reverted
fairly soon.

But I have to think about all of this some more.  The plan was to leave
things as is, and deal with it once I actually have the time to do so.
The above is just the very rough plan that I mostly formed before you
asked me to stop splitting up the package/repository.

My suggestion for the immediate future is that you distribute emacsql
and emacsql-sqlite as two separate packages and forgo distributing the
other backends (neither distribute them individually, nor as part of
emacsql).



reply via email to

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