all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jonas Bernoulli <jonas@bernoul.li>
To: Stefan Kangas <stefankangas@gmail.com>,
	Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [nongnu] main f4166f428a: * elpa-packages (emacsql): New package.
Date: Sat, 17 Dec 2022 03:01:49 +0100	[thread overview]
Message-ID: <87cz8izt2q.fsf@bernoul.li> (raw)
In-Reply-To: <87fsdezuh9.fsf@bernoul.li>

>> 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	other threads:[~2022-12-17  2:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <167091741978.18640.16217484079810212983@vcs2.savannah.gnu.org>
     [not found] ` <20221213074340.1C45BC000CE@vcs2.savannah.gnu.org>
2022-12-13 14:50   ` [nongnu] main f4166f428a: * elpa-packages (emacsql): New package Stefan Monnier
2022-12-13 18:52     ` Stefan Kangas
2022-12-15 16:10       ` Stefan Monnier
2022-12-15 20:37         ` Stefan Kangas
2022-12-15 21:05           ` Philip Kaludercic
2022-12-16  0:19             ` Stefan Kangas
2022-12-17  1:31           ` Jonas Bernoulli
2022-12-17  2:01             ` Jonas Bernoulli [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cz8izt2q.fsf@bernoul.li \
    --to=jonas@bernoul.li \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=stefankangas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.