jandamm/zgenom

Support Zsh Plugin Standard

jandamm opened this issue · 6 comments

jandamm commented

Taken over from: tarjoilija/zgen#104

https://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html

My thoughts:

I'd like to support the zsh plugin standard but I'm not really sure of the benefit of most "rules".

  • $ZERO why not just use $0?
  • $LOADED_PLUGINS 👍
  • $ZPFX zgenom doesn't support hooks, what is the benefit of setting ZPFX when the hooks aren't used anyways?
  • *_unload zgenom doesn't allow to unload plugins.

@psprint

psprint commented

Thanks for interest in implementing the standard. The answers to your questions:

  • $ZERO – it allows to have the options posix_argzero or function_argzero set,
  • $ZPFX – the plugin might still test for the parameter in it's body, plus implementing it is very easy,
  • *_unload – yes, so it might not implement this feature; however implementing a zgen unload … call would be a nice addition to zgen and it would allow to unload e.g.: agkozak theme (it implements the unload function).
jandamm commented

Would the ZPFX be a prefix somewhere in the filesystem or would it be in the realm of zgenom?
Because the former would have to be OS specific.

psprint commented

I think that it should be in ~/.zgen.

  • 👍1
jandamm commented

@psprint I've added most of the zsh plugin standard.

I'm don't like 3. Binaries Directory that much. In my opinion bin is a too common name to automatically add it to the $PATH.
When writing a plugin I'd naturally create a folder bin to store all internal executables and wouldn't expect the plugin manager to automatically add it to the $PATH.

If the user of zgenom wants this behavior they can choose to do so by adding zgenom bin <repo> to their zsh config.
Maybe I'll add an option to enable rule 3.

Apart from 3. I haven't implemented 4-6 since they don't apply (yet).

svenXY commented

Just a side note: topgrade (see here: https://github.com/r-darwish/topgrade/blob/547df8d346e8a7689213299f6fbb1d5807988b44/src/steps/zsh.rs#L72) uses the existence of the ZPFX directory to determine if zinit is installed and fails if it isn't.

I already opened a MR there to use some other env var, but also wanted to mention it here. especially, since I wasn't able to understand the reason for setting ZPFX here as well.

jandamm commented

@svenXY the author of zinit described it here:
https://zplugin.readthedocs.io/en/latest/zsh-plugin-standard/#446_global_parameter_with_prefix_for_make_configure_etc

While zinit is probably the most popular plugin manager supporting ZPFX it's not an indicator for zinit and was meant to be provided by other plugin managers.

When I implemented the standard (and with it ZPFX) I was under the impression that this pattern was widely used. In the end I think it was only used by the author of zinit and the standard.
But I also don't see a point in removing it.