Propose your package to NonGNU ELPA or GNU ELPA?

[minad]

No description provided.

[mohkale]

Hmmm, I am interested in the new non GNU ELPA. I'll try to include it there :-).

Also, should probably update the README, this package is available on MELPA as well.

[mohkale]

One slight complication is:

*** The package must follow the rules in
   https://www.gnu.org/prep/standards/, node References.  This means it
   may not refer users to any nonfree software or nonfree
   documentation, except as stated there.  Leading users to run a
   program, and suggesting they run it, or depending on it to be
   installed, are forms of referring users to it.

Since this package essentially expects users to have linters installed and runnable, it might infringe on this if we ever add support for a linter that doesn't have a free-license or is documented in a non-free way.

I'll still reach out to the NonGNU ELPA maintainers but I think it'll probably be rejected 😓.

[minad]

Okay, then MELPA is probably a better place. Would it make sense to split this package into non free and free components? It seems like an artificial distinction, but personally I don't have interest in using any proprietary linters.

[mohkale]

Would it make sense to split this package into non free and free components?

Perhaps. I think it'll be fine if we only contain definitions for free linters in this repo, and then create a separate package containing ones for non-free linters (honestly I've never seen or heard of one, but it probably exists somewhere). Slightly more cumbersome but freedom has its costs ;-).

I'll have to double check the licenses of all the ones that're already defined but otherwise should be fine if we commit to only keeping free ones on here. I'll see how receptive the emacs-developers are to this package beforehand though :-).

[minad]

I suggest you write an email directly to Stefan Monnier, the main ELPA maintainer. He will give you good feedback. Btw, why did you call your package flymake-rest? What about flymake-collection? This sounds more positive somehow.

[mohkale]

I suggest you write an email directly to Stefan Monnier, the main ELPA maintainer. He will give you good feedback.

Great, thanks :-).

Btw, why did you call your package flymake-rest? What about flymake-collection? This sounds more positive somehow.

I suck at naming things... 😭.

Honestly the initial idea was something like "the rest of flymake"; as in the command to pick and run a checker is a core flymake feature that isn't included by default, so you find it here; similarly flycheck has a tonne of checkers built-in but flymake has basically none.

But pretty much any name would've been fine to me so long as it was reasonably short. rest had 4 characters so I thought it was fine. In retrospect collection or all would've definitely been clearer. Not sure if it's worth the effort but maybe a name change should be in order.

[minad]

I think the package should be renamed. Also the package description is meaningless "Core features for flymake". For some reason nobody noticed your package. It needs a better description a better name and you may want to post it somewhere, e.g., on reddit. Currently flymake-rest has 11 downloads on https://melpa.org/#/?sort=downloads. I think it could do much better. :)

[mohkale]

I think the package should be renamed

Howdie @minad, I agree renaming it makes sense. What do you think about flymake-all? As in all the checkers for flymake.

[minad]

I prefer flymake-collection or flymake-backends but there are many possible names 🤷

[mohkale]

flymake-collection makes the most sense, although I'd prefer to have kept the second word to less than 4 characters 😄. I'll fork this repo into a new repository when all the open PRs are merged, update MELPA, then update this repo with a message that says it's been moved to a new name and users should migrate. Hopefully it should be a seamless transitiion. Apart from s/flymake-rest/flymake-collection/g everywhere.

[minad]

I know but this is a bad reason and you shouldn't sacrifice a good name because of that. I also use short names for my packages, but having flymake- in front is already a burden to get started with :-P

[mohkale]

Hi, package has been renamed, a new major version released, all functions and options renamed, and old names declared obsolete. You likely won't be able to build from master until melpa#7988 is imerged since I've also moved all elisp files into a src subdirectory, so the existing recipe won't be able to build it.

I'll leave this issue open to track any issues users may have during this transition.

In regards to including in non-GNU ELPA. I haven't recieved any response yet and I'm unsure whether this package would even be eligable for it so I'll leave it as something low-priority to investigate later.

[minad]

Oh great! Please also improve the description.

;;; flymake-collection.el --- Core features for flymake

What about these?

;;; flymake-collection.el --- Collection of missing flycheck checkers for flymake
;;; flymake-collection.el --- Collection of checkers for flymake filling the gaps to flycheck
;;; flymake-collection.el --- Checker collection, bringing flymake to the level of flycheck

[mohkale]

Checker collection, bringing flymake to the level of flycheck

Last one seems the nicest IMO :-).

[minad]

And then you may want to announce your package again somewhere, e.g., https://www.reddit.com/r/emacs/. You should probably also mention https://github.com/purcell/flymake-flycheck as alternative. Also mention alternatives in the README, e.g., https://github.com/purcell/flymake-flycheck? The README could be clarified further that you are interested in maintaining this repository as catching ground for additional checkers. I mean instead of saying that it is only meant for the transition from flycheck.

[mohkale]

And then you may want to announce your package again somewhere, e.g., https://www.reddit.com/r/emacs/.

Probably a good idea. I'll wait until the MELPA PR is done and then announce on reddit :-).

The README has been updated now. Thanks for the advice.

[mohkale]

Hiya, flymake-rest has been renamed to flymake-collection and I've announced it on reddit. :-).

[phikal]

When proposing to add a package to ELPA, it is best to message the emacs-devel mailing list, instead of any individual person. I would suggest doing so, as your package does seem very interesting, and perhaps could even be partially merged into Flymake itself.

As to the question about non-free checkers, I cannot say how pervasive these are. Does Flycheck use any non-free ones? One might also argue that amongst Emacs users there would be less interest in such software, but then again an Emacs user is not necessarily a Free Software advocate.

[minad]

@phikal I disagree. It is better to first ask individuals for feedback since the discussions on emacs-devel are mostly not productive.

[phikal]

I do understand what you mean, but the ELPA README does explicitly ask for requests to be sent to emacs-devel. The reason I recommend it is that more people will see it, and yes that means there is more potential for unproductive discussions, but it also reduces the chance of anyone missing or forgetting to respond to a message.

[minad]

@phikal I am not saying that one shouldn't send to the emacs-devel mailing list, one should! As you say, the README explicitly requests this to notify everyone. But it is more helpful to specificially ask knowledgeable individuals like Stefan Monnier first for feedback to resolve some specific questions, e.g., questions about the nonfree checkers here. If you mention nonfree checkers in your emacs-devel email, the discussion will likely not be productive, since then people will quickly jump on you because of this. Also many people on emacs-devel are actually not interested in ELPA, it makes sense to specifically send a mail to those who are. In my comment above, the emphasis is on the word first.

[minad]

@phikal Maybe it would be better if ELPA inclusions would be treated via a bug tracker, similar to how it is done for MELPA? Then interested people could subscribe to that bug tracker mailing list. One could still send a summary to emacs-devel. But having one issue per package would feel more effective, since then you have the guarantee that you will get a response and the procedure for inclusion is more formalized. Did you consider this when working on NonGNU-ELPA?

[phikal]

Personally I wouldn't be that concerned, if @mohkale were to post a non-provocative question I don't fear that a non-productive discussion would result. After all, it is just a message. As I am interested in this package, I could also take over the initial proposal, and CC anyone interested. The other points should be discussed elsewhere, as nobody here gets to decide these things anyway.

[phikal]

ping @mohkale?

[mohkale]

@phikal

Well, it has been a while since I reached out and gotten no updates yet. I don't see any harm in asking the ELPA mailing list themselves. Worst case I'll just get a polite no. :-).

[phikal]

Did anything happen since May?

[mohkale]

I did get a response. There's interest in adding to ELPA, or maybe even to Emacs mainline. There was also the suggestion of maybe using functions instead of macros for checkers. I've since mostly backlogged it as something to work on in the future (not a high priority IMO since MELPA works fine). It might be worth creating a new issue to track this however.

[phikal]

Mohsin Kaleem ***@***.***> writes:

I did get a response. There's interest in adding to ELPA, or maybe even to Emacs mainline.

I could take over add it to ELPA, and I think it would be a good addition. It seems to me that this would be a better first step before adding it to the core, though that would be a good long-term goal.

There was also the suggestion of maybe using functions instead of macros for checkers.

IMO I think that would be an improvement. Reading through some of the examples I tend to think that the cognitive load is too high in some places and it be simplified.

I've since mostly backlogged it as something to work on in the future (not a high priority IMO since MELPA works fine). It might be worth creating a new issue to track this however.

Here or on the Emacs bug tracker?

[mohkale]

I could take over add it to ELPA
Here or on the Emacs bug tracker?

That would be appreciated. I'll go ahead and re-open this issue as in progress.

IMO I think that would be an improvement

Fair point, I wanted the checkers to be more schema than implementations. Most of the details are abstracted over using helper functions behind the macros which makes making small changes or new checkers quite straightforward and compact. I'd be interested to see how this direction goes as well :-).

[jgarte]

@phikal Just wanted to mention that flymake-collection is in GNU Guix as of October. See #9. Nicolas Goaziou had reviewed and merged the Guix package.

[phikal]

jgart ***@***.***> writes:

@phikal Just wanted to mention that `flymake-collection` is in GNU Guix. See #9.

Sadly this doesn't change anything about the addition of flymake-collection to either of the ELPAs. Come to thing of it, what was the blocking issue for adding the package to NonGNU ELPA?

[mohkale]

Come to thing of it, what was the blocking issue for adding the package to NonGNU ELPA?

Nothing really. There was even the mention backporting it to emacs propper and perhaps implementing as some sort of a function instead of a macro. Adding this package to NonGNU ELPA is on my TODO list but I'm not sure when I'll be able to get back to it.

[phikal]

I can take care of adding the package to NonGNU ELPA. The advantage will be that everyone who tracks ELPA changes will be kept up to date to how to package is evolving and you'll get some more feedback on how to improve the package. As long as you take care to ask if new contributors have signed the FSF CA, it will be possible to move the package to GNU ELPA (a minor improvement) or even the core to be part of Emacs 30.

Has the situation with the non-free checkers been resolved? @jgarte how has Guix handled that issue?

[jgarte]

@jgarte how has Guix handled that issue?

To my knowledge Guix and FSF is agnostic to code that is FOSS even if it is meant to interact with proprietary software/backends. For example, we have a telegram client which we maintain, that is only supposed to interact with proprietary software on a server somewhere. I think they would maybe handle it by just having you read this: https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html But maybe don't quote me on that. If you'd like I'd recommend emailing ***@***.*** to discuss it if it is concerning. Which ones are the proprietary linters btw? I took a look here but didn't see any still https://github.com/mohkale/flymake-collection/tree/release/src/checkers

even the core to be part of Emacs 30.

I agree that flymake-collection should be part of Emacs core. That would be great!

[phikal]

jgart ***@***.***> writes:

> @jgarte how has Guix handled that issue? To my knowledge Guix and FSF is agnostic to code that is FOSS even if it is meant to interact with proprietary software/backends.

The term "backend" is fuzzy, the material question is does a program provide its full functionality without the need for the user to use non-free software. If the flymake-collection contains a non-free checker with no alternative, then the condition is not given and we cannot add the package to NonGNU ELPA, let alone proceed with adding the checkers to GNU ELPA/emacs.git.

For example, we have a telegram client which we maintain, that is only supposed to interact with proprietary software on a server somewhere.

That is different because a service is not a program you run on a device you are entitled to have control over in the first place. If you had to install a non-free library to communicate with telegram, then this would be a different situation, since you are restricted in exercising your freedoms in regards to software operating on your device.

I think they would maybe handle it by just having you read this: https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html But maybe don't quote me on that. If you'd like I'd recommend emailing ***@***.*** to discuss it if it is concerning. Which ones are the proprietary linters btw?

I don't recall the details, but I remember there being some discussion. If that has changed, then the issue is noop and we can forget it.

…

I took a look here but didn't see any still https://github.com/mohkale/flymake-collection/tree/release/src/checkers > even the core to be part of Emacs 30. I agree that flymake-collection should be part of Emacs core. That would be great!

[jgarte]

> Which ones are the proprietary linters btw? I don't recall the details, but I remember there being some discussion. If that has changed, then the issue is noop and we can forget it.

minad had mentioned it above but didn't mention which linters were proprietary... To me they all look to be free but I haven't thoroughly checked. mohkale WDYT

[phikal]

jgart ***@***.***> writes:

>> Which ones are the proprietary linters btw? > > I don't recall the details, but I remember there being some discussion. > If that has changed, then the issue is noop and we can forget it. minad had mentioned it above but didn't mention which linters were proprietary... To me they all look to be free but I haven't thoroughly checked. mohkale WDYT

I just checked the repository, and it seems that all the current checkers are OK. Was the issue perhaps instead that non-free checkers might be added in the future? And I also recalled another issue, namely that that `flymake-collection-define` is defined as a large marco, and it would be better to use a function instead. Skimming through the source it seems this was done to define a function, but that could have been achieved using a (fset function-name (lambda (...) ... )) as well.

[jgarte]

I just checked the repository, and it seems that all the current checkers are OK.

@phikal That's good to hear! thanks for the infos

[jgarte]

Adding this package to NonGNU ELPA is on my TODO list but I'm not sure when I'll be able to get back to it.

@mohkale Keep us posted and good luck on submitting it!

[phikal]

Ping? Is there any way one could help out?