Re: [NonGNU ELPA] New package: project-store

On Sun, Aug 16, 2026 at 1:36 PM Lin Jian <[email protected]> wrote:

> Stéphane Marks <[email protected]> writes:
>
> > How about the namespace "project-nix" and elide "store" entirely to
> > keep it short?
>
> Thanks for the suggestion.
>
> I think project-nix is clearly worse a name than project-store:
>
> - project-nix is more generic and has no clear definition: what is a
>   project nix or what is a nix project?  Is it a project containing some
>   .nix files?  For example, does adding a few .nix files to Emacs make
>   Emacs a nix project?  Is it a project mostly consisting of .nix files?
> - Store and project are the keys of this package.  Besides "store" and
>   "project", it is reasonable to add "nix" or "nix and guix" to the
>   name.  But it is absurd to remove "store" from the name, same as
>   removing "project" from the name.
>
> (BTW, I am curious why you suggest project-nix which your previous
> arguments apply to perfectly.  Am I missing something?)
>

Because it's about project.el and sharing that namespace makes sense as
your prefix suggests.  The notion of a "store" is not universal despite
your rhetoric suggesting it is.  At more than one large company in my past,
I designed what are unrelated precursors to Nix, accomplishing the precise
thing, though implemented very differently.  I would not consider our
shared assets that happen to be addressable via a file system naming
convention to be a "store."  So it's not a universal term for the concept,
it's a Nix term.

Hence project-nix or if you really must insist, project-nix-store despite
that terminology saying zero about what it is to anyone except an educated
Nix user.

> That Nix/Guix are colloquially called
> > "stores" by some is not the detail that matters for this package, IMO.
>
> No, it is not that Nix/Guix are colloquially called "stores" by some.
> Store is a key concept in them, a key concept that has top-level
> sections in both their reference manuals, a key concept that the 3rd
> sentence of "NixOS homepage -> Get started -> How Nix works" is
> "Nix stores packages in the *Nix store*."
>
> You seem to have some interesting opinion or understanding on this
> topic.
>

You seem to be suggesting that everyone else in the Emacs world will share
your Nix experience and background and somehow know what a store is.

> The first link I get when I Google nix store is
> > https://search.nixos.org/packages which doesn't even mention the word
> > store anywhere.
>
> Yes, this link is irrelevant.  I have shared my different Google results
> of "nix store" before and also a few useful links.
>

It wasn't irrelevant to me doing the precise thing that hundreds of other
people would do only to find no references to the store concept.  I clearly
see this differently.

(I am still wondering what you are implying via your web search results.
> Are you saying store is not a key concept of Nix?  Otherwise, I do not
> see how you web search results are relevant here.)
>
> > I'm aware that Nix supports
> > several kinds of "stores" and using the word store in the package might
> suggest support for them all; e.g., the http binary
> > cache, the s3 binary cache, etc.  Even "project-nix-local" would be more
> precise if you intend to support only that store.
>
> Actually, suggesting support for them is completely a bad thing.  It can
> invites potential contributor to add support for them.  This is a big
> advantage of "project-store": it gives room to future extension and
> invites contribution.
>

Only in your mind since you like "stores" whatever those are and which are
not a generic thing they are Nix/Guix specific as a naming convention for
their implementation approach.  They were not the first by decades of my
own experience having built, as I said, "stores" for giant distributed
computing environments without using the word store or using Haskell or Nix
or Guile or Guix.

> As ELPA is considered a part of Emacs, I think it is a collectively good
> thing that package names are well chosen
>
> Agree.
>
> It just that different people have different concerns and
> understandings, so their well chosen names may be different.
>
> To be clear, I do not choose the current name randomly.  I love to make
> informed choose as I mentioned before.
>
> > avoid potential conflicts in the future.
>
> What potential future conflicts are you having in mind?
>

Namespace conflicts in the project- prefix.  Perhaps someone would want to
use the -store suffix in a more generic, non-Nix way in the future.