Use a more standard package source layout

mohkale / flymake-collection

Collection of checkers for flymake

MIT License

68 stars 13 forks source link

Use a more standard package source layout #17

Open dmitrig opened 1 year ago

dmitrig commented 1 year ago

As far as I could tell, all packages in elpa are either a single file or a single source directory. Those that don't put the elisp in the root of the repository call the source dir "lisp" or "elisp". Putting checkers in a separate directory currently causes a few issues:

Using package-install-file to install the package from a local checkout fails
Using Emacs 29's package-vc-install-from-checkout also fails
The default flymake diagnostic function elisp-flymake-byte-compile doesn't work on checkers without extra configuration

mohkale commented 1 year ago

Thanks for this. I'm OK moving src/ to lisp/ but I'd rather not keep all checker src files in the same directory as the helper files. I expect it to grow rapidly over time and find the separation much easier. It'd be nice if Emacs had a way to forward declare the layout of a project :thinking:.

dmitrig commented 1 year ago

Agreed, it's not ideal. Other solutions might be to:

combine flymake-collection-commands.el and flymake-collection-define.el into flymake-collection.el. All other files in the lisp/ dir will be checkers, which will be relatively tidy
split flymake-collection into two packages, e.g. flymake-collection vs flymake-collection-lib, with source in separate dirs. This is probably overkill if the goal is to just keep the source layout nice

mohkale commented 1 year ago

Of those two I think the second approach is preferable. I'm not big fan of combining separate concepts into one big file for convenience :thinking:. Although it would end up being a bigger change, it should be possible to make it backwards compatible. First we'd need to create a new repo flymake-collection-checkers, add it to MELPA, then remove the checkers from this repo and add it to this repo. There's also the option to split in the opposite direction (we might have to given MELPAs rules on namespacing following the package name and the fact we dont want to have to rename the checker functions themselves since users will likely have them hooked in).

dmitrig commented 1 year ago

Sure, up to you, but IMHO it's probably not worth jumping through hoops just to avoid the single flat directory layout that emacs packages use. As a user/someone that's hacked on the code here a bit, I'd greatly prefer the first option vs. dealing with multiple repos.