Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic <philipk@posteo.net>]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>> For the sake of a constructive discussion, please don't make claims like
>> these without any further references.  Provocations like these, from
>> anyone, only make discussions like these more difficult.
>
> Oh, damn - I mixed a private thread with Philip and the message I had
> sent here. (I had reached out to him before posting here, as I was
> hoping to avoid a public thread on the topic) :double-facepalm:
> Anyways, that's on me.

No worries.  I prefer public conversations anyway, saves me from the
burden of archiving for myself ;)

>> I do not follow MELPA development or statistics, but from what I recall
>> these are just accumulated downloads over all versions, right?  If so,
>> then the information we get from this fact is rather low.
>
> Fair enough. Still, you don't get to #4 in the all-time rankings on
> past usage alone. I'm sorry that I can't provide better usage metrics
> to support my case.

I get what you mean, but what is really missing is growth statistics,
specifically w.r.t. new, manual installations.  MELPA also inflates for
packages that commit a lot, since they have more "releases", hence more
updates, and hence finally more downloads.  We can certainly conclude
that it is a package that people payed attention to, but I just want to
avoid inferring too much from that.

>> Could you explain how this relates to the current state of Flymake
>> vs. Flycheck?  The fact that Flymake caught up, and in my eyes
>> deprecated Flycheck, seems like a success story.
>
> I'm afraid I don't have the time to do a detailed research on the
> current state of Flymake. I haven't written the comparison page myself
> and I agree some points there are small/subjective. I'm not sure how
> you came to the conclusion that Flycheck got deprecated, though. 

Sorry, "deprecated" should have been in quotes;  perhaps "superseded"
would be the more appropriate term.  My point is just that there was a
time where Flycheck had advantages, in a certain milieu, but I think
that period is over and that is good.

>                                                                  Any
> analysis that I would do would be subjective of course, from mine
> perspective and from yours, so I think it wouldn't change anything.
>
> To be clear I don't want to argue which project is better and what are
> the merits of Flycheck over Flymake, if any. If it's so big of a deal
> to have packages that duplicate core functionality in the official
> repos - fine.

I'd qualify this as "duplicate existing functionality provided via ELPA,
without providing a characteristic advantage".  The fact that Flymake is
built-in is an important, but secondary point.

>> As you say, people will continue
>> maintaining third-party repositories that accept every brittle little
>> scripts anyone writes (I speak here from experience and personal
>> suffering), but I think it is a feature that ELPA has a more curated
>> policy.  I for my really try my best to raise the bar of package
>> submissions, and while it is not always easy, I hope that this helps
>> make the system more robust for everyone. 
>
> I get your point about quality, but here we're not talking about some
> random package of questionable provenance. You can inspect the
> codebase yourself if you want, but (subjectively speaking) has fairly
> clean codebase, lots of unit tests, and very detailed
> documentation. (and a sizeable, if hard to measure user-base)
> Flymake's docs
> (https://www.gnu.org/software/emacs/manual/html_node/emacs/Flymake.html)
> are pretty basic compared to Flycheck's so I feel you're applying
> double standards here.

(I really can't write) My above comment was on MELPA in general,
specifically deriving from my first few years of using Emacs before
getting into development (~2014-2020) -- a position I would argue that
most core developers /and/ MELPA contributors have not experienced --
and the issues and misconceptions I had to overcome.  While I cannot
recall any specific breakage related to Flycheck, the mentality of
having to install everything from MELPA, without properly studying the
documentation or understanding the potential synergy that Emacs can
provide, did keep me back for a long time, and as I regularly observe,
hinders others from advancing as well.  But that is a topic for another
thread, that should probably take place on some other mailing list...

> Anyways, I had a feeling I'd regret asking for the inclusion of Flycheck. I'll take is that my answer is "No".
>
> I really don't want to turn this into some heated debate, so we can just wrap up here. 

OK, thank you anyway for the idea.

> On Mon, Feb 19, 2024, at 8:53 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> 
>> > There is a detailed comparison here
>> > https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html
>> 
>> From what I see, this comparison is outdated and somewhat one-sided.
>> Flymake has error explanations, and categories like "Automatic syntax
>> checking" seem disingenuous if the complaint is that there is not a
>> flymake-global-mode.  (It would have probably taken less time to write a
>> `define-globalized-minor-mode', than the time to write this point...)
>> 
>> > but many of the differences are probably not important to many
>> > people. You might remember that before Flycheck, Flymake was in a
>> > state of disarray and abandoment for years, so I'm pretty sure
>> > Flycheck making it almost obsolete back then was the trigger for some
>> > modernization around Emacs 26.1. 
>> 
>> Could you explain how this relates to the current state of Flymake
>> vs. Flycheck?  The fact that Flymake caught up, and in my eyes
>> deprecated Flycheck, seems like a success story.
>> 
>> >                                  And the contributors to Flycheck and
>> > Flymake were always pretty different - part of the reason Sebastien
>> > (the original author of Flycheck) quit Emacs were some attacks he was
>> > getting on emacs-devel.
>> 
>> For the sake of a constructive discussion, please don't make claims like
>> these without any further references.  Provocations like these, from
>> anyone, only make discussions like these more difficult.
>> 
>> > Many people are so off-put by the discourse there, that they want to
>> > have as little as possible with it. And that's the real value of
>> > alternative packages IMO - they allow us to harvest the energy of all
>> > contributors.
>> 
>> I don't think this is the problem you are making it out to be, and even
>> if it were, one could have a package like flymake-collection added to
>> NonGNU ELPA.
>> 
>> > Btw, flymake-flycheck was created only because Joao wouldn't agree to
>> > provide Flycheck support in Eglot (I know this from the author of
>> > flymake-flycheck). The whole situation with Elgot was a classic
>> > example of the hostility in Emacs towards packages some maintainers
>> > dislike... (https://github.com/joaotavora/eglot/issues/42)
>> 
>> I don't know how you infer, but again, it would be nice to keep the
>> discussion here on-topic instead of bringing up old drama between
>> GNU-adjacent/core development and MELPA/GitHub/anti-GNU people.
>> 
>> >> but considering that
>> >> more and more people rely on LSP for the information (and Eglot supports
>> >> Flymake OOTB), I don't know how valuable this is.
>> >
>> > Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users
>> > flycheck by default for its error diagnostics. I'm not a big LSP user,
>> > though, and often prefer the simplicity of just shelling out to
>> > whatever lint tools I need.
>> 
>> The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a
>> problem in this case.
>> 
>> > You probably know that Flycheck is one of the most download packages
>> > on MELPA, so it has plenty of happy users. 
>> 
>> I do not follow MELPA development or statistics, but from what I recall
>> these are just accumulated downloads over all versions, right?  If so,
>> then the information we get from this fact is rather low.
>> 
>> (BTW. if we are to implement this feature for ELPA, then we should pay
>> attention to avoid this mistake, and only display the download counts
>> over some fixed time interval, e.g. the information currently available
>> in the access logs.)
>> 
>> >                                            
>> >                                            I'm one of them and that's
>> > why I took over the maintenance of the project. I felt that NonGNU
>> > ELPA existed to make it easier for popular stuff to be installed by
>> > users, but it seems to me MELPA won't be going away any time soon.
>> 
>> NonGNU ELPA is not only a means of making more useful packages readily
>> available to users OOTB (without having to search online blogs and fora
>> for code snippets that enable third-party archives and install dozens of
>> weirdly named packages replicating built-in functionality), but also a
>> chance to clean up the package landscape, and prune away some
>> experiments from the 2010s.  As you say, people will continue
>> maintaining third-party repositories that accept every brittle little
>> scripts anyone writes (I speak here from experience and personal
>> suffering), but I think it is a feature that ELPA has a more curated
>> policy.  I for my really try my best to raise the bar of package
>> submissions, and while it is not always easy, I hope that this helps
>> make the system more robust for everyone.  So once more, please do not
>> assume malice in these discussions, I don't think anyone here hates one
>> another or intentionally wants to hinder them personally.  It takes
>> effort to take others seriously, but it is worth undertaking if we want
>> to make Emacs better.
>> 
>> To this end, I repeat my question: What _technical functionality_ does
>> Flycheck _currently_ provide that Flymake does not?  A different way of
>> putting it is what architectural advantages does Flycheck exemplify over
>> Flymake, that give it an inherent edge?  If there aren't too many
>> differences, I think the cost of confusion (Flymake and Flycheck are
>> names that are easy to confuse) and of inducing choice-fatigue among new
>> users is not something we should ignore.
>> 
>> > On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
>> >> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> >> 
>> >> > Hey everyone,
>> >> >
>> >> > Just wanted to ask if there's any interested in adding Flycheck
>> >> > (https://www.flycheck.org/en/latest/), a popular alternative to
>> >> > Flymake, to NonGNU ELPA?
>> >> >
>> >> > You can find the codebase here https://github.com/flycheck/flycheck
>> >> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
>> >> >
>> >> > I'm not sure what's the stance of adding alternatives to built-in
>> >> > packages in general, but I think providing some alternatives to the
>> >> > end users is not a bad thing overall.
>> >> 
>> >> My main question is what advantage Flycheck has over Flymake.  I
>> >> understand it has a database of tools built-in, but considering that
>> >> more and more people rely on LSP for the information (and Eglot supports
>> >> Flymake OOTB), I don't know how valuable this is.  In addition to that,
>> >> there are projects like
>> >> 
>> >> https://github.com/mohkale/flymake-collection
>> >> https://github.com/purcell/flymake-flycheck
>> >> 
>> >> that could help bridge the gap.
>> >> 
>> >> 
>> 
>>