Refactor and v2 API

[viperML]

This is a major refactor for wrapper-managaer, basically rewriting it from sratch by learning from past mistakes.

There is a new function called wrapWith, to create a single wrapper:

wrapper-manager.lib.wrapWith pkgs {
  basePackage = pkgs.hello;
  prependFlags = ["-g" "Hi"];
}
# => «derivation /nix/store/...»

---

If you are not using flakes, the calling API has changed, please apply these changes:

Old way of evaluating wrapper-manager without flakes:

let
  url = "https://github.com/viperML/wrapper-manager/archive/refs/heads/master.tar.gz";

  wrapper-manager = import (builtins.fetchTarball url) {
    inherit (pkgs) lib;
  };
  
  eval = wrapper-manager.lib {
    inherit pkgs;
    modules = [ ... ];
  };
in
  ...

New way of evaluating wrapper-manager without flakes:

let
  url = "https://github.com/viperML/wrapper-manager/archive/refs/heads/master.tar.gz";

  wrapper-manager = import (builtins.fetchTarball url); # don't eval this
  
  eval = wrapper-manager.lib {
    inherit pkgs;
    modules = [ ... ];
  };
in
  ...

[viperML]

Marking as draft as this is incomplete for now.

[nrabulinski]

I know it's still WIP so just leaving comments about things that immediately caught my eye

[viperML]

@nrabulinski this should be ready to review.

There's a problem in that mkRemovedOptionModule is implemented in terms of assertions, which is not part of evalModules but rather integrated into NixOS.

Me we can just do a one-off thing for deprecating .flags.

(For the record, my dotfiles are already using this branch)

[nrabulinski]

There's a problem in that mkRemovedOptionModule is implemented in terms of assertions, which is not part of evalModules but rather integrated into NixOS.

I work around this in wrapper-manager-hm-compat, by evaling assertions when creating the wrappers, you can see it here. Would be nice to have that upstream actually.

[viperML]

There's a problem in that mkRemovedOptionModule is implemented in terms of assertions, which is not part of evalModules but rather integrated into NixOS.

I work around this in wrapper-manager-hm-compat, by evaling assertions when creating the wrappers, you can see it here. Would be nice to have that upstream actually.

Looking at the modules, what I don't know is how to load assertions.nix for each option that has a submodule, and collect all assertions for all submodules.

[viperML]

In the end I did a one-off thing to deprecate .flags. We can look at implementing .assertions in a later PR.