sellout / project-manager Goto Github PK

Project Manager should include a comment in generated files that indicates that the file is generated, and ideally also where the definitions that generate it come from.

This isn’t always possible (e.g., JSON doesn’t allow comments), but in other cases we can provide a wrapper on the standard lib generators that automatically includes such a heading.

Perhaps this could be upstreamed to the nixpkgs generators (parameterized over the system that generates the files).

In some contexts project-manager switch works fine, but in others it runs against the MacOS version of Bash, which is too old for anything.

E.g., nix run github:sellout/project-manager -- switch on a Mac currently fails. The workaround is to do

nix develop github:sellout/project-manager
project-manager switch
exit

which forces the environment to have Nix’s Bash.

Should provide options similar to https://flakehub.com/new and produce a new workflow in the GH module.

If a devShell has inputsFrom = [checks.${system}.formatter] and the formatter is set via the treefmt module, entering that devShell will run the formatter check, rather than just making treefmt available in the shell.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update nixpkgs to release-24.05

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Currently Project Manager requires a flake. However, it should be fine to have it work without a flake, using some heuristics (finding a repo directory like .git) to set PROJECT_ROOT and find the config in the default location.

It could produce a project-manager.nix that defines a shell that can be referenced by shell.nix. And perhaps also add a project-manager develop command that will try nix develop $PROJECT_ROOT#project-manager || nix-shell $PROJECT_ROOT/project-manager.nix.

https://devenv.sh/ and https://flake.parts/ are both similar to Project Manager in some ways. Write up how they are different and when you might want to use one or another.

This causes an issue when different versions of packages in different Nixpkgs releases have different file formats.

E.g., 23.11 has Vale 2.29 and 24.05 has Vale 3.0, which changes the location of vocabularies. We need to generate both for all the tests to pass. But in general projects would only be using one version of Vale, and would only want those files generated.

One of the issues with committing generated files is that they can get out of date. Project Manager knows which files it’s persisting, so it can provide a suite of flake checks (or a single composite check) to make it easy for flakes to make sure they’re up-to-date.

Related: Project Manager should be able to self-add git (and other VCS?) pre-push hooks to run checks, etc. (and ensure those hooks are current in the same set of checks …).

Basically, diff the outputs produced by Project Manager for two arbitrary git SHAs.

Since we’re trying to minimize what gets committed, or even copied to the worktree, this gives us a way to still check what the effect of various changes is on the generated files.

Publishing to pages is a lot of rendundant code. The bulk of the workflow should be produced automatically (along with some github settings) and then projects only need to set whether it should be populated from a branch or actions, and (if actions), the with arguments to pass to nix-develop-command.

E.g., the config should look like one of the following:

services.github.pages = {
  enable = true;
  branch = "docs";
};

or

services.github.pages = {
  enable = true;
  action = {
    command = ''
      idris --mkdoc iaia.ipkg
      ## We copy here to fix the permissions from the Nix symlinks
      cp -r ./iaia_doc ./_site
      chmod --recursive +rwx ./_site
    '';
    devshell = "iaia";
  };
};

Modules that integrate with GH should produce a list (or attrset, if there’s useful metadata) of the GH checks they produce.

Then the ProBot GH settings module can be fed those (with the ability to filter) to create the list of required GH checks.

Stealing more from Home Manager – use https://gitlab.com/rycee/nmt/ and do it much like https://github.com/nix-community/home-manager/blob/68f7d8c0fb0bfc67d1916dd7f06288424360d43a/flake.nix#L90-L94

E.g., Haskell cabal files can contain the set of compilers they were tested with. Populate this from Project Manager.

Lots of tools generate CTAGS, but it’s important that they stay up to date and the relevant tools can be configured in project-manager without requiring that tags files are committed to the repo.

E.g., for Nix, nix run github:lf-/nix-doc -- tags will build them. If configured, Project Manager should both build them and provide a check to ensure they’re current (if they’re committed).

These are just preliminary thoughts

There could be six ways to configure Project Manager (top is the most general):

flowchart BT

project --> defaults
pu["project user"] --> project
hpg["host path glob"] --> defaults
upg["user@host path glob"] --> hpg
wt["working tree"] --> pu
wt --> upg

• defaults is just what is built into Project Manager itself, all the module defaults. These apply everywhere and is already supported.
• project is configuration committed to the repo (by default this is in $PROJECT_ROOT/.config/project/, and this is already supported).
• working tree is specific to the particular working tree it’s in. This isn’t yet supported. It could default to $PROJECT_ROOT/.config/project/local/ and should not be committed. This is probably the next most useful case.
• project user is specific to a user & a project. This isn’t yet supported. It should be committed and would ideally just be conditionalized config within project, but maybe just stored in like $PROJECT_ROOT/.config/project/user/$VCS_USER/ (where VCS_USER is some VCS-specific identifier, like git config user.email). If a user prefers to not commit their configuration, this can generally be approximated with either working tree or user@host path glob configurations.
• path glob (host & user@host) is a pretty flexible last case (that isn’t yet supported). It should be stored in /etc/project-manager/ or $XDG_CONFIG_HOME/project-manager/, respectively. It applies its configuration based on the working tree directory, relative to HOME. It mostly subsumes working tree, but with some tradeoffs. E.g., a key of "Projects/personal/some-project" would exactly match that one project directory (same as working tree in that project directory), while "Projects/personal/**" would match projects at any depth in $HOME/Projects/personal/. Other patterns like "**/some-project would match project directories with that name at any location (within the user’s home directory), and "**" applies as broadly as possible. The tradeoffs with working tree are that path glob can match multiple working trees and the configuration is resilient to deleting and re-creating the working tree, but the configuration isn’t stored with the project and user@host path glob does not play well with working trees that are shared by multiple users (which is why the paths are relative to home, and why host path glob exists – but host path glob has permission complexities). And another benefit over working tree is that path glob can easily be added to a NixOS, nix-darwin, or Home Manager configuration that is shared between hosts (which can approximate an uncommitted project user config, as alluded to above).

Comparing to Git scopes:

• defaults is akin to Git’s defaults,
• working tree is akin to --worktree (or --local),
• user@host path glob is akin to --global,
• host path glob is akin to --system, and
• project & project user have no equivalent in Git scopes, as Git explicitly tries to prevent you from committing configuration.

Some checks (e.g., Vale’s¹) currently need to disable the chroot. The way it's currently handled, they are just regular checks, so you need to either manually exclude them from your flake or set sandbox = false if you want to nix flake check. Setting sandbox = false in the flake has already bit me on multiple occasions, so I want to get rid of that.

There are a few different thoughts I've had for managing this:

• provide a way to add only sandboxed checks to the flake
• add an option to include the unsandboxed checks as devShells instead
• make use of the lax-checks devShell that sort of exists to bundle all of the unsandboxed checks similarly to nix flake check

All three is probably the way to go. Additionally, it'd be great to automatically generate GH or other CI jobs for unsandboxed derivations, since garnix can't run them.