Minimal configuration API

[akirak]

The current schema has a lot of fields. Most of them can be configured interactively using the Emacs frontend, but having more fields means more manual work in maintenance.

I am not sure if I am going to work on the next version of this program, but I will track information on how it could be simplified in case someone else may develop an alternative.

An assumption is that a MELPA recipe seems to be necessary, given that the service is the current de-facto standard package registry for developers. As a proof, both melpazoid and keg.el take a recipe as input.

• [x] pname can be derived from the recipe
• [x] version looks unnecessary. It is mostly used for checking version consistency in multi-file packages.
• [x] files can be derived from the recipe if it is specified
• [x] emacsVersion can be read from the package header
• [x] localDependencies can be load from the package configuration itself
• [x] dependencies: https://github.com/nix-community/emacs-overlay/pull/38 looks promising
• [ ] testDrivers
• [ ] ertTests
• [ ] buttercupTests
• [x] testDependencies is (partly) equivalent to devDependencies in Cask, so it can be detected if Cask file is available
• [ ] testExcludes
• [x] mainFile can be guessed from the package name
• [ ] recipe can be downloaded from MELPA once it is published, but it would be better to set it locally

An ideal solution would be to have no configuration file at all, but I am susceptible if it is possible.

[akirak]

Apparently, it is necessary to add some explicit information on testing, so I don't believe in zero-configuration testing right now.

[akirak]

Also note that ert-runner seems to be the test driver of choice among many developers, while there are some people (including me) who prefer buttercup: https://www.reddit.com/r/emacs/comments/hc8y51/ann_a_github_action_for_emacs_lisp_ci/fvdtuof/

[akirak]

It might be possible to start separate projects for linting and testing. While linting can be done with zero configuration (assuming there is a recipe), testing will require some additional configuration and allow for more complex settings for its environment. The linter probably can be standardized once there is an agreement (e.g. among people on MELPA) on what package developers are responsible for, but there will still remain unstandardized settings in testing. Developers have their different, respective criterion on testing.

[akirak]

Nonetheless, testing frameworks could partly benefit from the infrastructure for linting, e.g. for installing dependencies, so it will be useful to think about a generic solution.

[akirak]

I have implemented helper functions for parsing Cask files and MELPA-style recipes in Nix: nix-elisp-helpers. I am also working on another project to get recipes from a local copy of MELPA, which every elisp developer should have on computer. With these stuffs, it will become much easier to set up CIs on existing projects.

[akirak]

I am currently working on a new branch v4 to reduce the code and improve performance issues of the previous version. It reflects the ideas described in this ticket. It is mostly written in Nix and bash.

[akirak]

It looks much better than before, so I'll close this issue.