Test pkgs

.gitignore

@@ -10,3 +10,7 @@
 !flake.lock
 !LICENSE
 !README.md
+!hello
+!hello/**
+!test
+!test/**

hello/.gitignore

@@ -0,0 +1,7 @@
+# ignore all
+*
+
+# and then whitelist what you want to track
+!.gitignore
+!test
+!test/**

hello/test/.gitignore

@@ -0,0 +1,7 @@
+# ignore all
+*
+
+# and then whitelist what you want to track
+!.gitignore
+!hi
+!hi/**

hello/test/hi/.gitignore

@@ -0,0 +1,9 @@
+# ignore all
+*
+
+# and then whitelist what you want to track
+!flake.lock
+!CONTRIBUTE.md
+!.gitignore
+!flake.nix
+!README.md

hello/test/hi/CONTRIBUTE.md

@@ -0,0 +1,36 @@
+# Contribute to hello/test/hi:
+<!--
+What are the prerequisites for contributing to the code?
+    * provide users with containerized development environments, virtual machines, or, if developing for an embedded system, a pre-built OS image. Don't make them set up an environment from scratch.
+-->
+## Develop:
+<!--
+Tell your reader how to run the code in the development environment
+-->
+### Repository Structure:
+<!--
+List each file, and what it does.
+    * Identify whether you are open to pull requests for a specific file or not.
+-->
+| File or Folder | What does it do? | When should you modify it? |
+| :------------- | :--------------- | :------------------------- |
+|                |                  |                            |
+## Test:
+<!--
+When the reader runs the code, what are the expected inputs and outputs?
+How can the reader tell if the code is malfunctioning?
+-->
+## Document:
+<!--
+How should the reader document changes and additions to the code?
+-->
+## Deploy:
+<!--
+How is the code deployed? When the reader submits a pull request, how is the code merged into main and converted into a package?
+-->
+<!--
+Additional tip: SHOW, don't TELL
+* DON'T try to sell your reader on using your code. Don't spend words on clever analogies or context. That material is great for a blog post or video, but bad for the documentation included in repository. Your reader wants to run the code, not read about it. Help your reader get to 'hello world' as fast as possible.
+* DO make diagrams. A diagram can help your reader organize information in ways that words alone can't.
+    * Do not put more than 50 nodes and edges into a single diagram. It will turn into an indecipherable spaghetti-string mess. Keep diagrams simple.
+-->

hello/test/hi/README.md

@@ -0,0 +1,46 @@
+# hello/test/hi
+<!--
+Add a banner image and badges
+see: https://towardsdatascience.com/how-to-write-an-awesome-readme-68bf4be91f8b
+For bonus points, make the banner animated with html, css and svg
+see: https://github.com/sindresorhus/css-in-readme-like-wat
+-->
+<!--
+Start with WHY:
+    * What is the problem, and why does it exist?
+    * Why does the problem need to be solved?
+    * Why is your code the best way to solve the problem?
+            * Where does the problem originate?
+            * how does your code fix the problem at its origin?
+        * What is the alternative to your code?
+        * Compared to the alternative
+            * How much more time and money does your code save?
+            * How much more technical debt does your code avoid?
+            * How does your code improve the developer experience?
+-->
+<!--
+List any codebases, websites, apps, platforms or other products that use your code
+  -->
+<!--
+link to your reader to your repository's bug page, and let them know if you're open to contributions
+-->
+## How to use hello/test/hi:
+<!--
+Link to a webpage, web shell (e.g. runkit), or downloadable executable that demonstrates the project.
+        * note that when the reader is modifying the code, they will compare their modified version to the demo to see if their changes worked as they expected them to. Your demo is their reference
+-->
+### Installation:
+<!--Explain how to import the modules of the project into the reader's codebase, install the containers of the project in the reader's cluster, or flash the binary of the project onto the reader's hardware-->
+### API Methods | Modules:
+<!--
+List the methods or modules your project provides.
+-->
+## How Project Name works:
+<!--
+Explain how execution works. What is the entry point for your code? Which files correspond to which functionality? What is the lifecycle of your project? Are there any singletons, side effects or shared state among instances of your project? Take extra care to explain design decisions. After all, you wrote an ENTIRE codebase around your opinions. Make sure that the people using it understand them.
+-->
+## Roadmap:
+<!--
+List the releases that you have added to each project, and any future releases you would like to do. If there is a date for future release, put it here. If not, let people know that there is no defined timeframe for future releases.
+-->
+## [Contribute](./CONTRIBUTE.md)

hello/test/hi/flake.nix

@@ -0,0 +1,92 @@
+# see parse-manifest-flake_nix.nix to find out how
+# project-lint, project-lint-semver, project-build, and
+# project-test are run against this flake
+{
+  description = "build and test for hi";
+
+  inputs = {
+    flake-schemas.url = "https://flakehub.com/f/DeterminateSystems/flake-schemas/*";
+
+    nixpkgs.url = "https://flakehub.com/f/NixOS/nixpkgs/0.1.*";
+  };
+
+  outputs = {
+    flake-schemas,
+    nixpkgs,
+    self,
+    ...
+  }: let
+    supportedSystems = [
+      "x86_64-linux"
+      "aarch64-linux"
+      "x86_64-darwin"
+      "aarch64-darwin"
+    ];
+    forEachSupportedSystem = f:
+      nixpkgs.lib.genAttrs supportedSystems (system:
+        f {
+          pkgs = import nixpkgs {inherit system;};
+        });
+  in {
+    # https://determinate.systems/blog/flake-schemas/#defining-your-own-schemas
+    schemas =
+      flake-schemas.schemas
+      // {
+        nixVersion = {
+          version = 1;
+          doc = "The nix version required to run this flake";
+          type = "string";
+        };
+      };
+
+    # nixVersion specifies the nix version needed to run this flake
+    nixVersion = "2.33.1";
+
+    packages = forEachSupportedSystem ({pkgs}: {
+      default = pkgs.stdenv.mkDerivation {
+        name = "hi";
+        src = "../../../"; # Include entire repo as source
+        version = "0.0.3";
+
+        nativeBuildInputs = with pkgs; [
+          coreutils
+          # INCLUDE THE TOOLS YOU NEED TO BUILD YOUR PACKAGE HERE
+        ];
+
+        phases = [
+          # "unpackPhase"
+          # "patchPhase"
+          # "configurePhase"
+          "buildPhase"
+          # "checkPhase"
+          # "installPhase"
+          # "fixupPhase"
+          # "installCheckPhase"
+        ];
+
+        buildPhase = ''
+
+          # make dirs included in package FHS
+          # see https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
+          #
+          mkdir -p "$out"/{bin,lib,share,include}
+
+          # copy executables to bin/ so they can be nix run
+          # copy libraries to lib/
+          # copy docs, data to share/
+          # copy headers to include/
+        '';
+      };
+    });
+
+    checks = forEachSupportedSystem ({pkgs}: {
+      exampleTest =
+        pkgs.runCommand "exampleTest" {
+          nativeBuildInputs = [self.packages.${pkgs.system}.default];
+        } ''
+          # name of bin to run default package
+          echo "test passed" > "$out"
+        '';
+    });
+  };
+}

test/.gitignore

@@ -0,0 +1,7 @@
+# ignore all
+*
+
+# and then whitelist what you want to track
+!.gitignore
+!another
+!another/**

test/another/.gitignore

@@ -0,0 +1,9 @@
+# ignore all
+*
+
+# and then whitelist what you want to track
+!CONTRIBUTE.md
+!flake.lock
+!.gitignore
+!README.md
+!flake.nix

test/another/CONTRIBUTE.md

@@ -0,0 +1,36 @@
+# Contribute to test/another:
+<!--
+What are the prerequisites for contributing to the code?
+    * provide users with containerized development environments, virtual machines, or, if developing for an embedded system, a pre-built OS image. Don't make them set up an environment from scratch.
+-->
+## Develop:
+<!--
+Tell your reader how to run the code in the development environment
+-->
+### Repository Structure:
+<!--
+List each file, and what it does.
+    * Identify whether you are open to pull requests for a specific file or not.
+-->
+| File or Folder | What does it do? | When should you modify it? |
+| :------------- | :--------------- | :------------------------- |
+|                |                  |                            |
+## Test:
+<!--
+When the reader runs the code, what are the expected inputs and outputs?
+How can the reader tell if the code is malfunctioning?
+-->
+## Document:
+<!--
+How should the reader document changes and additions to the code?
+-->
+## Deploy:
+<!--
+How is the code deployed? When the reader submits a pull request, how is the code merged into main and converted into a package?
+-->
+<!--
+Additional tip: SHOW, don't TELL
+* DON'T try to sell your reader on using your code. Don't spend words on clever analogies or context. That material is great for a blog post or video, but bad for the documentation included in repository. Your reader wants to run the code, not read about it. Help your reader get to 'hello world' as fast as possible.
+* DO make diagrams. A diagram can help your reader organize information in ways that words alone can't.
+    * Do not put more than 50 nodes and edges into a single diagram. It will turn into an indecipherable spaghetti-string mess. Keep diagrams simple.
+-->

test/another/README.md

@@ -0,0 +1,46 @@
+# test/another
+<!--
+Add a banner image and badges
+see: https://towardsdatascience.com/how-to-write-an-awesome-readme-68bf4be91f8b
+For bonus points, make the banner animated with html, css and svg
+see: https://github.com/sindresorhus/css-in-readme-like-wat
+-->
+<!--
+Start with WHY:
+    * What is the problem, and why does it exist?
+    * Why does the problem need to be solved?
+    * Why is your code the best way to solve the problem?
+            * Where does the problem originate?
+            * how does your code fix the problem at its origin?
+        * What is the alternative to your code?
+        * Compared to the alternative
+            * How much more time and money does your code save?
+            * How much more technical debt does your code avoid?
+            * How does your code improve the developer experience?
+-->
+<!--
+List any codebases, websites, apps, platforms or other products that use your code
+  -->
+<!--
+link to your reader to your repository's bug page, and let them know if you're open to contributions
+-->
+## How to use test/another:
+<!--
+Link to a webpage, web shell (e.g. runkit), or downloadable executable that demonstrates the project.
+        * note that when the reader is modifying the code, they will compare their modified version to the demo to see if their changes worked as they expected them to. Your demo is their reference
+-->
+### Installation:
+<!--Explain how to import the modules of the project into the reader's codebase, install the containers of the project in the reader's cluster, or flash the binary of the project onto the reader's hardware-->
+### API Methods | Modules:
+<!--
+List the methods or modules your project provides.
+-->
+## How Project Name works:
+<!--
+Explain how execution works. What is the entry point for your code? Which files correspond to which functionality? What is the lifecycle of your project? Are there any singletons, side effects or shared state among instances of your project? Take extra care to explain design decisions. After all, you wrote an ENTIRE codebase around your opinions. Make sure that the people using it understand them.
+-->
+## Roadmap:
+<!--
+List the releases that you have added to each project, and any future releases you would like to do. If there is a date for future release, put it here. If not, let people know that there is no defined timeframe for future releases.
+-->
+## [Contribute](./CONTRIBUTE.md)