Add to (Non)GNU ELPA? about emacs-direnv

[manuel-uberti]

Right then. We can close this I guess. Thanks for sharing your opinion.

[phikal]

wouter bolsterlee ***@***.***> writes:

@phikal thanks, automagic updates look good. do i understand correctly that this auto-updating works like melpa stable? so not `git main` (like melpa unstable), but explicit version? do git tags matter? or is it the version in the `.el` file?

Yes, a cron job regularly fetches the remote repository, and checks the version in the .el file. If a commit changes this and (version-list-< old-version new-version) then a new release is published.

reason for the above questions is that i do _not_ want to take extra effort to update stuff in various repos that redistribute my packages. git push/tag and keeping a version number up-to-date is fine of course, but i will not be pinging people or sending emails etc.

Nope, none of that should be necessary, if anything goes wrong we might just ping you.

re license: this package is BSD, direnv itself is MIT. this package has a clear and narrow scope, namely direnv and emacs, both of which are foss, so i guess this is fine.

I agree.

however, let it be clear that i will not let people whose (often bad) opinions i don't care about (rms comes to mind in particular) tell me in any way what i can or cannot write in my own readme etc. i don't buy the ‘unethical’ and ‘moral issue’ nonsense rhetoric, and i will not be dragged in that direction either.

Things like a README aren't relevant to ELPA, at most there might be a comment on stylistic issues in the Elisp files. (While I'm at it, I might mention that a reference to a README can be inconvenient when you are previewing a package using C-h P. That just displays the content of the "Commentary" section, and I think it is nice if that is self-contained.)

that said, i guess i agree with you that this is a non-issue here.

So you are fine with adding the package to NonGNU ELPA?

…

-- Philip Kaludercic

[wbolster]

🤔 what would be the actual benefit? since any sufficiently fancy emacs setup uses melpa packages anyway, at least that's what i see around me

(fwiw, without referring to anyone in particular, in general i don't consider emacs "upstream" a particularly welcoming environment, and i don't look forward to using inconvenient outdated development processes and interacting with gnu zealots.)

[manuel-uberti]

The actual benefit would be that without adding extra configuration (e.g., enabling MELPA) one could install your package right away.

[manuel-uberti]

since any sufficiently fancy emacs setup uses melpa packages anyway

FWIW, yours is the only MELPA package I am using right now. :)

[wbolster]

that nongnu elpa thing is not (yet?) enabled by default so using it seems the same amount of effort as using melpa.

that said, i agree with the sentiment here.

https://emacsredux.com/blog/2021/08/02/nongnu-elpa-package-repository/

anyway, fine with me if someone who is not me submits my packages (i wrote many!) elsewhere and (automagically) keeps them up-to-date (like melpa), but i don't see myself spending any effort on it

[phikal]

I should add that RMS asked me to explicitly bring up the NonGNU ELPA rules for new packages: https://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org#n120 We can add the package, and enable auto-updating whenever the "Version" tag is updated, but only if you are ok with these requirements (it's nothing controversial, mostly the endurance that there are no dependencies on non-free software. From a brief look at the code and the functionality, this seems like a non-issue). Given your ack, I can take care of the rest.

…

-- Philip Kaludercic

[wbolster]

@phikal thanks, automagic updates look good. do i understand correctly that this auto-updating works like melpa stable? so not git main (like melpa unstable), but explicit version? do git tags matter? or is it the version in the .el file?

reason for the above questions is that i do not want to take extra effort to update stuff in various repos that redistribute my packages. git push/tag and keeping a version number up-to-date is fine of course, but i will not be pinging people or sending emails etc.

re license: this package is BSD, direnv itself is MIT. this package has a clear and narrow scope, namely direnv and emacs, both of which are foss, so i guess this is fine.

however, let it be clear that i will not let people whose (often bad) opinions i don't care about (rms comes to mind in particular) tell me in any way what i can or cannot write in my own readme etc. i don't buy the ‘unethical’ and ‘moral issue’ nonsense rhetoric, and i will not be dragged in that direction either.

that said, i guess i agree with you that this is a non-issue here.

[wbolster]

So you are fine with adding the package to NonGNU ELPA?

sure, now that i know it doesn't create busywork for me, ship it. 🚀

re readme vs .el: i don't know of a nice solution here. copy/pasting stuff increases maintenance load, and a properly rendered readme on github etc is more useful in the end.

[phikal]

wouter bolsterlee ***@***.***> writes:

> So you are fine with adding the package to NonGNU ELPA? sure, now that i know it doesn't create busywork for me, ship it. 🚀

Great!

re readme vs `.el`: i don't of a nice solution here. copy/pasting stuff increases maintenance load, and a properly rendered readme on github etc is more useful in the end.

May I suggest something like ;; Direnv (https://direnv.net/) integration for Emacs. ;; Enable the global `direnv-mode' minor mode to have inferior shells, ;; linters, compilers, and test runners start with the intended ;; environmental variables. ;; Using the command `direnv-allow' you can mark a ".envrc" as safe ;; (remember to always first check if it trustworthy) This clarifies that the package integrates with a remote tool and mentions the entry points (direnv-mode, direnv-allow) so that a potential user knows what they are dealing with. More than this it's necessary. If they want to find out more, a link to the GitHub repository is always also available.

…

-- Philip Kaludercic

[wbolster]

sure, pull requests welcome 👍🏼