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

Lin Jian <[email protected]> writes:

> Hi,

Hi,

> I would like to add my package project-store to NonGNU ELPA.
>
> It is a project.el backend for Nix store.  Guix users may also find it
> useful.  The full README is available at the end of this email.

Can you clarify what this means?  From what I understand, this is
suppose to be a backend that interprets every directory underneath
/nix/store as a project, right?

> You can find its code at <https://github.com/jian-lin/project-store>.

A few comments:

- I wouldn't refer to README in Commentary, it would be nice to have a
  brief summary of the package in that place.

- If you want to suggest compatibility with Guix, would it make sense to
  have the type of `project-store-dir' also include a constant for
  /gnu/store/?  What if someone uses both Guix and Nix (or other forks)?

- Do you really want to include project-store-benchmark.el and
  project-store-tests.el in the package, or should they be excluded in
  .elpaignore?

- I think you can simplify `project-store--try-without-cache' using
  `locate-dominating-file', something like

    (locate-dominating-file dir (lambda (dir*) (string= (file-name-parent-directory dir*) project-store-dir)))

- Do you need to use the not-found constant in `project-store-try'?  Or
  can't you just simplify the entire expression to the
  `with-memoization' block without `or'?

- Why is `project-store-p' autoloaded?

- How much of a difference does the caching make?  If it does, would it
  make sense to split the caching from the actual logic of the package
  and have a (cache . PROJECT-BACKEND) backend that just implements the
  caching and then simplify your backend logic?  The former could be
  added directly to project.el.  I have added Dmitry to the CC list for
  comments.