Tracking issue for Paq 2.0

[savq]

State management and reproducibility

• [x] #107
• [x] #73
• [x] #80
• [x] #99
• [x] #150
• [ ] Look into packspec client requirements, and write a new issue with a roadmap for implementation.

Update code base

• [x] Update minimum requirements to nvim 0.7:
  • [x] #148
  • [x] Use lua for command and autocmd defintions.
• [x] Refactor run_hook. All hooks must be run after packloadall.
• [x] Rename run option to build (soft deprecation).
• [x] Remove redundant paq export (has been deprecated since forever). Keep register.
• [ ] Refactor call_proc. See #123

Release

• [x] Update the (very outdated) CHANGELOG.md
• [x] Create github release and tag commit

[justinmk]

fwiw, if/when Nvim includes a package manager I'm pretty convinced it will be based on paq because it's so small. Not sure the lockfile feature is needed though.

[saccarosium]

@justinmk do you have a better/more sensible solution?

The idea of the lockfile that represent the previous state seems a good idea, since would simplify a lot of the logic. Now is in a very primitive state but I think could become the foundation for better usability over the behavior that paq provide now.

[justinmk]

The idea of the lockfile that represent the previous state seems a good idea, since would simplify a lot of the logic

If it simplifies the logic then it's good :) Probably https://github.com/neovim/packspec should define pkg.lock.json ...

[savq]

Probably https://github.com/neovim/packspec should define pkg.lock.json ...

Yes! If packages can define dependencies, there has to be a file that describes all the packages in the system. Otherwise it'll be hard for users to understand (let alone debug) their package setup.

[saccarosium]

I was thinking that after 2.0 we could make install paq as a file into the lua directory in peoples config, like what plug does in the autoload folder. This would make paq a lot more portable and people would just have it in their dotfiles.

For installing we could have a script that curl paq and the documentation into the apropriate spot. And for updating we could provide a simple script that compares the two files and updates to the new one and re-pulls the docs down.

[saccarosium]

@savq I've implemented all the state management feature in the todolist but I wanted to ask if you agree with some of my decision regarding how I've handled the different scenario:

• branch changed: Paq will silently reinstall the plugin without the user knowing (see function reclone)
• remote changed: same as branch
• opt/start directory: Paq will move silently the plugins in the currect location

How it works

Paq at the when is called with the packages will confront the difference between the configuration and the lockfile (done with the diff_populate function) and will populate a table of pkgs called Diff of what is different with the following format:

Diff = {
  [name] = {
    -- ...pkg...
    status = {TO_MOVE|TO_RECLONE}
  }
}

On every command (clear, install, update and sync) Paq will check if there are diffs to be handled in Diff. This is done with the diff_resolve function.

After some testing I didn't found any major problems, but I think we should make a test suite for testing the edge cases.

[telemachus]

savq I've implemented all the state management feature in the todolist but I wanted to ask if you agree with some of my decision regarding how I've handled the different scenario:

• branch changed: Paq will silently reinstall the plugin without the user knowing (see function reclone)
• remote changed: same as branch
• opt/start directory: Paq will move silently the plugins in the currect location

FWIW, as a user I agree with this design. If I've changed the branch, remote, or opt/start directory in my configuration, then I've asked for the changes. I shouldn't need extra confirmation.

[savq]

• branch changed: Paq will silently reinstall the plugin without the user knowing (see function reclone)
• remote changed: same as branch

That's is fine for now.

I believe there's a command that could work here, But I haven't tried it yet:

git switch --force-create <branch> --track <remote>/<branch>

• opt/start directory: Paq will move silently the plugins in the currect location

Yes. This should be the default. As telemachus said, if the user changed their config, then there's no need for confirmation.

On every command (clear, install, update and sync) Paq will check if there are diffs to be handled in Diff.

I don't think this should be done on :PaqClean.

Everything else on dev looks good!

[saccarosium]

I believe there's a command that could work here, But I haven't tried it yet:

git switch --force-create <branch> --track <remote>/<branch>

Seem interesting I should take a look on that

I don't think this should be done on :PaqClean.

As is for now we don't have a choice since if the diff is not resolved PaqClean will delete the package, since it think is an unlisted package.