sellout / project-manager Goto Github PK
View Code? Open in Web Editor NEWHome Manager, but for repos.
Home Page: https://sellout.github.io/project-manager
License: MIT License
Home Manager, but for repos.
Home Page: https://sellout.github.io/project-manager
License: MIT License
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.
These updates are awaiting their schedule. Click on a checkbox to get an update now.
These updates have all been created already. Click a checkbox below to force a retry/rebase of any.
.github/workflows/flakehub-publish.yml
actions/checkout v4
.github/workflows/flakestry-publish.yml
.github/workflows/pages.yml
flake.nix
nixpkgs release-22.11
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
$PROJECT_ROOT/.config/project/
, and this is already supported).$PROJECT_ROOT/.config/project/local/
and should not be committed. This is probably the next most useful case.$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./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:
--worktree
(or --local
),--global
,--system
, andSome checks (e.g., Vale’s1) 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:
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.
In the case of Vale, I want to add a valeWithPackages
to Nixpkgs so that Vale packages are just derivations and don't break the sandbox. But this issue still holds more broadly. ↩
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.