Adding `exec-path-from-shell` to NonGNU ELPA

[skangas]

Hi @purcell,

I would like to suggest adding exec-path-from-shell to NonGNU ELPA. I think you're already aware of the implications, but to re-iterate, the only technical requirement I see is adding a correct ;; Version: header.

What do you think?

[purcell]

I'm not averse to doing this sort of thing, for various projects, but can you point me to info about the appropriate process? ie. Are things still driven off tags, what about when master evolves for months but a Version header isn't updated etc.? What can go wrong, and what do I need to be aware of? This lack of info is what has held me back from doing anything, since my time is currently super limited.

[skangas]

I'm not averse to doing this sort of thing, for various projects, but can you point me to info about the appropriate process? ie. Are things still driven off tags, what about when master evolves for months but a Version header isn't updated etc.? What can go wrong, and what do I need to be aware of?

Alas, there is no such resource besides the README, which admittedly is a bit of a long read. (I'm thinking about maybe putting together a FAQ, but nothing like that exists, yet.) So I hope the following answers will suffice:

• Unlike MELPA Stable, NonGNU ELPA does not use git tags. The ;; Version: header is the only thing that matters. When that header is bumped to a higher version, the commit where that is made will be used as the basis for as a new version.
• If master evolves for months, but the Version header is not updated, no release will be made. NonGNU ELPA is configured to automatically update all changes from your master branch. There is an optional devel archive available, which always has the latest version directly from git (just like MELPA).
• The NonGNU ELPA maintainers occasionally open issues on the bug tracker of various packages to remind them to bump the Version, but that process is not formalized in any way.
• Force pushes generally create problems, so they should be avoided unless absolutely necessary. NonGNU ELPA automatically pulls in commits, so the branches risk diverging, thus creating more work for everyone.
• The only other requirement is that we ask that packages only recommend free/libre software. I don't think this is an issue in the case of exec-path-from-shell.

As for the process, I'm happy to make all necessary changes on our end to add the package. You only need to bump the Version header when you think it makes sense.

This lack of info is what has held me back from doing anything, since my time is currently super limited.

Understandable, and thank you in advance. Please let me know if you have any other questions or concerns.

I hope that helps.

[purcell]

A bit late, but version header is now added, and I'll maintain that in future, so feel free to add to NonGNU ELPA if that's helpful to folks.

[skangas]

Thanks!

Philip Kaludercic has now added the package: https://elpa.nongnu.org/nongnu/exec-path-from-shell.html

[purcell]

Great, thanks for letting me know!

[schneeschmelze]

Important and great news indeed. Thanks for sharing. YMMV, but I think the package should become a regular part of GNU Emacs for macOS.

[skangas]

YMMV, but I think the package should become a regular part of GNU Emacs for macOS.

I think we will welcome volunteers working on solving this issue in Emacs core, indeed.

If anyone wants to work on that, please open a new feature request/bug report.

[purcell]

YMMV, but I think the package should become a regular part of GNU Emacs for macOS.

Maybe. These days I personally favour a healthy and responsive package ecosystem that can receive updates between Emacs releases rather than a huge central standard library. IMO most of the significant progress in the wider ecosystem over the last 10 years has taken place this way, except where core Emacs facilities like tree-sitter and module support have been required to enable them. But I understand there are different views.

[skangas]

Maybe. These days I personally favour a healthy and responsive package ecosystem that can receive updates between Emacs releases rather than a huge central standard library. IMO most of the significant progress in the wider ecosystem over the last 10 years has taken place this way, except where core Emacs facilities like tree-sitter and module support have been required to enable them. But I understand there are different views.

Perhaps I'm missing your point, but I see no fundamental contradiction between bundling features with Emacs, and being able to update packages between releases: that's what :core packages are for. But I'm also not in favor of a "huge" central standard library, on the contrary. I'm definitely leaning towards being proactive about getting rid of cruft.

In my view, fundamental problems affecting every user of a port should be solved in core. It's rather unfortunate that many (most?) macOS users are currently more or less forced to unbreak Emacs by installing exec-path-from-shell.

That said, I'm happy that this package exists, of course, since it serves a real need.

[schneeschmelze]

Thanks for elaborating on your points of view. My suggestion stems from my recent experience with switching from Aquamacs to Vanilla. LuaTeX did not work out of the box when calling it from Emacs because it missed the values from environment variables. By now I need LuaLaTeX as standard engine. The problem is mentioned in the Emacs manual, but exec-path-from-shell is not. I'm not sure how to amend this, except for including the package in core. But, as said, YMMV. No reason to hurry, as search engines exist.

[purcell]

@skangas The situation is certainly better these days now that built-in packages can be updated between releases. And I certainly agree re. "fundamental problems affecting every user of a port should be solved in core".