New version: zplug 3.0.0

[babarot]

Problem Summary

• Refresh design mismatch
• Tags
  • Review load-order tag (defer tag ...): related to #314
  • I agree with introducing the negative number of the load-order
  • In that case, it is hard to understand that defer tag takes a negative number from the viewpoint of the tag name
  • Moreover, I can not agree to take a wide range like nice tag which was introduced in the past
  • Behavior changes with use tag depending on from tag is uncomfortable design
  • Since zplug was initially developed as a plugin manager for zsh, by default it'll load the file ending in zsh (*.zsh, *.plugin.zsh) as a plugin. However, this constraint is troublesome when dealing with commands, etc. For example, in from: gh-r internally use tag is rewritten by zplug. This is very confusing specification for the user. Also, since use tag is used for architecture selection when downloading use at from:gh-r, it can not be used to use the original use tag (selection of the file downloaded to $ZPLUG_REPOS)
  • Redesign from: gh-r in view of abolition
  • Because this tag is assumed to manage binary files hosted in releases only
  • Text file packages e.g. composer are difficult to handle due to this design's thought (see also #351)
    • Despite the existence of the rename-to tag, it is not cool implementation to rewrite the binary file name downloaded when being pecified gh-r tag
    • This meddling also prevents the installation of composer
  • It is also one inconsistency that converting use tag from the file glob to the regular expression
  • Make a tag parser for zplug
  • This is a specification but for now zplug cannot handle colon (see also #347)

What contents zplug should manage

It is also subject to gist, but we will not mention it here. Consider the as tag and the special case, but it's not about thefrom tag

• zsh plugin
  • should be sourced (*.zsh)
  • should be autoloaded
• completion file (_*)
• commands
  • binary (from GitHub releases, etc.)
  • text
• zsh theme (*zsh-theme)
• third party FW (mainly as zsh plugin)
  • oh-my-zsh
  • prezto
  • zim

Design philosophy

• New generation package manager
  • written by zsh script (for also managing zsh plugin)
• Wrapper tool with git command and git structure
  • Having the installation feature (downloading) and update feature
  • Can freely load the downloaded contents
  • e.g. as commands, plugin, etc

New interface plan

WIP

[agross]

Review load-order tag (defer tag ...): related to #314 Moreover, I can not agree to take a wide range like nice tag which was introduced in the past

The question that remains to be answered from my point of view is why you changed your mind w.r.t. to 39 nice values being OK for a whole year (I started using zplug at the end of 2015) to them being no longer OK.

Please keep in mind that taking away features will make the life of your users harder than necessary as they can no longer rely on features being there.

One way to get rid of nice/defer/whatever might be to load plugins in the order in which they are specified, perhaps with a single tag for stuff to load after compinit.

---

IMHO also worth discussing:

I have to admit that I find it very hard to follow zplug's versioning scheme. I think the zplug team should decide how the version numbers are incremented.

The current version scheme of major.minor.patch implies semver, at least to me. In the last months of using zplug I remember at least two breaking changes while upgrading patch releases.

[Defman21]

One way to get rid of nice/defer/whatever might be to load plugins in the order in which they are specified, perhaps with a single tag for stuff to load after compinit.

I were wondering about that for a while :)

[paulhybryant]

I don't think a single tag to load things after compinit is sufficient though. Some plugin might have dependencies on other plugins. One such example is zsh-users/zaw. If you want to use cdr, zsh-cdr must be loaded before zaw.

I think a wider value of nice/defer can help with this, and if we really want a single tag, a tag that can specify the dependencies can handle these use cases as well, with 'compinit' as a special dependency.

[sudoforge]

It is also subject to gist, but we will not mention it here. Consider the as tag and the special case, but it's not about the from tag ... completion file (_*)

Major support for this. Currently, it does not seem possible to use zplug to manage arbitrary scripts as command completion scripts. This is problematic when using zplug to install, for example, the hub cli tool -- as the way the repository is structured does not play well with the assumptions zplug makes about completion commands - specifically, that they exist in their own directory.

Consider this, which works just fine:

source "$HOME/.zplug/init.zsh"
zplug "docker/compose", use:contrib/completion/zsh

And this, which is broken and not possible:

source "$HOME/.zplug/init.zsh"
zplug "github/hub", use:etc/hub.zsh_completion, rename-to:_hub
# impossible to source the script at etc/hub.zsh_completion as a completion script

Personally, I'd prefer if the as:completion feature was merged in prior to "v3" -- I mean, that's the whole point of using semantic versioning's minor version numbers, to incrementally add features and then declare a new major when the collection of features for that major version have been integrated.

Currently, because it is impossible to use zplug to manage completion scripts (instead of assuming that completion scripts exist in their own directory and are named properly, like in the docker/compose example above), I've had to resort to manually maintaining a completion directory and manually downloading and sourcing the script, which is obviously not ideal and is the entire reason I moved to using zplug in the first place.

[raabf]

Redesigned from-tag with intelligent URL-like syntax and a single plain git source (please see #437, it would be too long to write it here)

[Vaesper]

Why does nice even need a specific allowed range? Can it not simply iterate through the values from lowest found to highest found, while defaulting to 0? Is there a technical reason to limit this?

[Cypher1]

@raabf Is this version still being worked on? Just wondering what the state of the project is. Thx