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

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

[Stefan Monnier]

>     * elpa-packages (emacsql): New package.
>     
>     * elpa-packages (emacsql-mysql): New package.
>     
>     * elpa-packages (emacsql-psql): New package.
>     
>     * elpa-packages (emacsql-sqlite): New package.
>     
>     * elpa-packages (emacsql-sqlite-builtin): New package.

To me this looks completely ridiculous: why split this into N packages,
when each one is tiny anyway.
Let's stop the madness and make it a single package.
Nobody (neither we, nor the users) benefits from having such tiny packages.


        Stefan

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

[Stefan Kangas]

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

> To me this looks completely ridiculous: why split this into N packages,
> when each one is tiny anyway.

The reason I did it like that is only that it was the path of least
resistance: it replicates what is currently there on MELPA.  This
matters because other packages depend on the existence of e.g. the
`emacsql-sqlite' package.[1]  If we want to add those packages as is, and
have them installable, their dependencies must also be in NonGNU ELPA.

> Let's stop the madness and make it a single package.
> Nobody (neither we, nor the users) benefits from having such tiny packages.

I see three options here:

1. We could make transitional packages on NonGNU ELPA that just depend
   on `emacsql'.

2. We can change the packages to be transitional on MELPA, too.

3. We can make _only_ the existing packages on MELPA transitional.

With option 2 or 3, I think we could convince maintainers to simply
depend on `emacsql' instead.  This should be done before adding the
packages to NonGNU ELPA (so we don't need any transitional packages
there).

Footnotes:
[1]  https://melpa.org/#/emacsql-sqlite

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

[Stefan Monnier]

Stefan Kangas [2022-12-13 10:52:38] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> To me this looks completely ridiculous: why split this into N packages,
>> when each one is tiny anyway.
> The reason I did it like that is only that it was the path of least
> resistance: it replicates what is currently there on MELPA.  This
> matters because other packages depend on the existence of e.g. the
> `emacsql-sqlite' package.[1]

But none of the packages in (Non)GNU ELPA depend on emacsql-<backend>,
so we don't really need to abide by the Melpa packaging.

I know I'm biased against such subpackages, but I'm really failing to
see the benefit of this particular split, so I think we should rectify
this in NonGNU ELPA rather than reproduce the Melpa structure for its
own sake.

> If we want to add those packages as is, and have them installable,
> their dependencies must also be in NonGNU ELPA.

I expect that can be changed when needed.

>> Let's stop the madness and make it a single package.
>> Nobody (neither we, nor the users) benefits from having such tiny packages.
> I see three options here:
> 1. We could make transitional packages on NonGNU ELPA that just depend
>    on `emacsql'.
> 2. We can change the packages to be transitional on MELPA, too.
> 3. We can make _only_ the existing packages on MELPA transitional.

I don't have any control over Melpa, so I can't choose 2 or 3, but
I don't see any need for those transitional packages in NonGNU ELPA.


        Stefan

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

[Stefan Kangas]

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

> But none of the packages in (Non)GNU ELPA depend on emacsql-<backend>,
> so we don't really need to abide by the Melpa packaging.

The main reason I've added emacsql to NonGNU ELPA is to be able to add
packages that depend on it (such as org-roam).  Those packages currently
depend on emacsql-<backend> packages.

>> If we want to add those packages as is, and have them installable,
>> their dependencies must also be in NonGNU ELPA.
>
> I expect that can be changed when needed.

Agreed.  Let's see what Jonas thinks about the plan I proposed.

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

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> But none of the packages in (Non)GNU ELPA depend on emacsql-<backend>,
>> so we don't really need to abide by the Melpa packaging.
>
> The main reason I've added emacsql to NonGNU ELPA is to be able to add
> packages that depend on it (such as org-roam).  Those packages currently
> depend on emacsql-<backend> packages.

Do you think it is plausible to get org-roam to switch to emacsql
without any specific subpackage?

>>> If we want to add those packages as is, and have them installable,
>>> their dependencies must also be in NonGNU ELPA.
>>
>> I expect that can be changed when needed.
>
> Agreed.  Let's see what Jonas thinks about the plan I proposed.

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

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> Do you think it is plausible to get org-roam to switch to emacsql
> without any specific subpackage?

I don't see why they shouldn't, but I'm waiting too see what Jonas
thinks about it.

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

[Jonas Bernoulli]

Stefan Kangas <stefankangas@gmail.com> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> But none of the packages in (Non)GNU ELPA depend on emacsql-<backend>,
>> so we don't really need to abide by the Melpa packaging.
>
> The main reason I've added emacsql to NonGNU ELPA is to be able to add
> packages that depend on it (such as org-roam).  Those packages currently
> depend on emacsql-<backend> packages.
>
>>> If we want to add those packages as is, and have them installable,
>>> their dependencies must also be in NonGNU ELPA.
>>
>> I expect that can be changed when needed.
>
> 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.

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

[Jonas Bernoulli]

>> 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).