search

purcell / package-lint

A linting library for elisp package metadata
GNU General Public License v3.0
191 stars 33 forks source link

Emacs dynamic modules (another "allow ignoring of errors" thread) #207

Open seanfarley opened 3 years ago

seanfarley commented 3 years ago

I love @purcell's work (and would marry him if I could) but I find myself between a rock and a hard place. I'm writing an emacs dynamic module (think web browser) where certain keybindings make sense that aren't recommended (e.g. ESC). Is there a way to keep using this package or compromise?

I guess the larger issue is that we're using emacs is a new and exciting ways with modules that I don't know how to align with pure lisp packages.

Either way, thanks for the work you do, Steve!

purcell commented 3 years ago

I love @purcell's work (and would marry him if I could)

You missed the boat on that one, sorry. 😁

Okay, so the issue here is that package-lint is - primarily - an opinionated tool to help review packages for MELPA purposes, and for package authors to pre-emptively perform some of that review themselves. Whether issues raised by the tool are considered blockers by the MELPA reviewers is still somewhat determined on a case-by-case basis. So that means it's hard to include package-lint in CI for cases where a MELPA reviewers says "X is okay" while package-lint says "X is bad": using the tool in CI is nonetheless desirable because it helps make sure new unrelated packaging issues don't show up over time.

Having given this some thought, I'm somewhat amenable to assigning each potential error class an ID, and allowing users to suppress/demote such errors, but it's important to me that all issues should be strictly checked for MELPA purposes.

I'm a little wary of the work involved, though, and the generally mixed message it sends about authors having free reign to decide what they care about. At the same time, it's nice to have error IDs because they can be linked to more descriptive text about the corresponding issue in a separate document, so I wonder if a good first step would be to assign error IDs in the existing code.

seanfarley commented 3 years ago

You missed the boat on that one, sorry. 😁

Can't blame a guy for trying, though. I mean, I hear New Zealand is lovely. 😅

Okay, so the issue here is that package-lint is - primarily - an opinionated tool to help review packages for MELPA purposes, and for package authors to pre-emptively perform some of that review themselves. Whether issues raised by the tool are considered blockers by the MELPA reviewers is still somewhat determined on a case-by-case basis. So that means it's hard to include package-lint in CI for cases where a MELPA reviewers says "X is okay" while package-lint says "X is bad": using the tool in CI is nonetheless desirable because it helps make sure new unrelated packaging issues don't show up over time.

I empathize with this so much. Honestly, I don't know what to do because the goals are so different (MELPA packages vs dynamic modules). I 100% appreciate the "one and true way" to lint. On the other hand, I want everything (including my web browsing!) in emacs!

I guess this comment really isn't saying much, to be honest. Just that I like New Zealand and like your work!

purcell commented 3 years ago

Haha, fair enough! 🤗

Note largely to self: a crude extension mechanism would involve supporting a package-lint-errors-filter-function custom var which the user could set in order to suppress (or perhaps change the level of) errors by inspecting their message.