chore: update proposals with working scripts / header updates

proposals/.tackle.yaml

@@ -27,7 +27,7 @@ Proposal<_:
     description: A list of proposal IDs to link to
     default: []
 
-get_all_proposals()<_:
+get_proposals()<_:
   files->: listdir --exclude ^tackle|scratch|templates|__pycache__|wip|.old
   output: []
   proposals->:
@@ -44,22 +44,22 @@ github_issue<-:
   repo: tackle
 
   get_by_num(issue_num int)<-:
-    data_>: http_get https://api.github.com/repos/{{org}}/{{repo}}/issues/{{issue_num}}
-    title->: var data.title
-    body->: var data.body
+    data:
+      _>: http_get https://api.github.com/repos/{{org}}/{{repo}}/issues/{{issue_num}}
+      headers:
+        Authorization: "token {{get_github_token()}}"
+        Accept: "application/vnd.github.v3+json"
+    return->: data
 
   update<-:
     issue_number: int
     title: str
     body: str
     status: str
-    github_token:
-      type: str
-      default->: get_github_token
     exec:
       ->: http_patch https://api.github.com/repos/{{org}}/{{repo}}/issues/{{issue_number}}
       headers:
-        Authorization: "token {{github_token}}"
+        Authorization: "token {{get_github_token()}}"
         Accept: "application/vnd.github.v3+json"
       json:
         title: "{{title}}"
@@ -79,14 +79,34 @@ update_header(p Proposal)<-:
     ---
   body->: update_section {{p.file}} {{var(header_tpl)}} start-header end-header
 
+update_readme()<-:
+  proposals->: get_proposals
+  status_map:
+    implemented: Implemented
+    accepted: Accepted
+    deferred: Deferred
+    considering: Considering
+    wip: WIP
+    rejected: Rejected
+    abandoned: Abandoned
+
+  readme_table:
+    ->: var
+    input: |
+      | Title | Status | Description | Blockers |
+      | --- | --- | --- | --- |
+      {% for p in proposals %}| [{{p.title}}]() | {{status_map[p.status]}} | {{p.description}} | {%for i in p.blockers%}[{{i}}]()<br />{%endfor%} |
+      {% endfor %}
+  update readme table->: update_section README.md {{readme_table}}
+
 <-:
   help: Update all issues
   exec:
-    do->:
-      for: p in get_all_proposals()
-      remote->: github_issue get_by_num p.number
-      body->: read_section {{p.file}} start-body end-body
-
+    Update Proposals->:
+      for: p in get_proposals()
+      remote->: github_issue get_by_num {{p.issue_num}}
+      Update title_>: update_header {{p}}
+      body->: read_section {{p.file}} start-header end-body
       Update Github_>:
         ->: github_issue update
         if: remote.title!=p.title or remote.body!=body
@@ -95,4 +115,4 @@ update_header(p Proposal)<-:
         body: "{{body}}"
         status: "{{p.status}}"
 
-      Update title_>: update_header {{p}}
+    Update Readmes->: update_readme

proposals/README.md

@@ -3,48 +3,48 @@
 [//]: # (DO NOT MODIFY - Generate with `tackle` in this directory)
 [//]: # (--start--)
 
-| Name | Status | Description | Blockers | Related To |
-| --- | --- | --- | --- | --- |
-| AST Upgrade | WIP | - |  | [] |
-| Abbreviate Kwargs | WIP | Allow kwarg flags to be shortened / abbreviated - ie `foo --bar baz` to `foo -b baz` | ast-parser<br />peg-parser<br /> | [] |
-| Allow hooks to be called in fields | WIP | Right now you can call hooks from rendering fields but would be great to use an arrow notation as well. |  | [] |
-| Command Arrow | Considering | Add a new arrow to indicate calling a command. |  | [] |
-| Complex Types | Implemented | Allow complex types including hook types |  | [] |
-| Context Composition | WIP | Upgrade the main context object from inheritance to a composition based model. |  | [] |
-| Declarative hook config parameters | WIP | Expose config parameters for pydantic's BaseModel to declarative hooks. |  | [] |
-| Default Methods as a Hook | Considering | Allow setting literal values if the first arg is |  | None |
-| Default hook | Implemented | When running a tackle file, it can help to have a default hook to run. |  | [] |
-| Default hook methods | Considering | None |  | [] |
-| Hook Access Modifiers | Implemented | Make hooks either public or private allowing distinction for what is in `tackle <target> help`. |  | [] |
-| Hook Defaults | Implemented | Declarative hook default values should be parsed for hook calls. |  | [] |
-| Hook Directory as the Base Directory | Accepted | This proposal would make the tackle file optional allowing the hooks directory to act alone. |  | [] |
-| Hook Methods | Implemented | Allow creating hooks within hooks that act like methods with parameter inheritance. |  | [] |
-| Improve Loop Parser | WIP | Improve the loop parsing logic to allow declaring variables, ie `for: i in a_list`.
- |  | ['peg-parser'] |
-| Overrides Improvements | WIP | Improve how overrides are tracked and applied when parsing files / hooks |  | [] |
-| PEG Parser | WIP | Update the current regex based parser to a PEG parser. |  | [] |
-| Partial Generation | Deferred | Generate / update parts of files instead of the whole file |  | [] |
-| Path Tracking Improvements | WIP | Modify how paths are tracked and made available through special variables. |  | [] |
-| Pydantic v2.0 Upgrade | WIP | Upgrade to pydantic version 2.0 |  | [] |
-| Remote Providers | WIP | Move the majority of the providers to remote locations |  | [] |
-| Reorganize the Providers | Implemented | Reorganize the providers into more logical groups. |  | [] |
-| Splat Operators | WIP | Allow splat operators to instantiate hooks - ie `a_hook **a_dict` or `a_hook *a_list` | ast-parser<br />peg-parser<br /> | [] |
-| Structured File Hook Shared Functions | Considering | Update all the structured file hooks (ie yaml, json, toml, and ini) to have shared functions. |  | [] |
-| URL Input Strings | Considering | Allow URLs to be input into tackle directly and make requests a dependency. |  | [] |
+| Title | Status | Description | Blockers |
+| --- | --- | --- | --- |
+| [Declarative Hook Config]() | Implemented | Allow hooks to have a model_config parameter exposing pydantic config params |  |
+| [Peg Parser]() | WIP | Change the parser from regex to PEG |  |
+| [Special Args]() | WIP | Reserve some arguments for use with tackle (ie import, freeze, update) |  |
+| [Tackle Test Rigging]() | WIP | None |  |
+| [Default Hook]() | Implemented | Allow files to have a default hook to be called when no arguments are supplied |  |
+| [Reserved Fields]() | WIP | Change the syntax of reserved fields to reduce potential conflicts |  |
+| [Hook Methods]() | WIP | Allow creating hooks within hooks that act like methods with parameter inheritance. |  |
+| [Provider Reorg]() | Implemented | Reorganize the providers into logical groups |  |
+| [Return Hook]() | Implemented | None |  |
+| [Hook Alias]() | WIP | Alias hooks so they can be called easier |  |
+| [Complex Type Use]() | WIP | Using complex types has issues |  |
+| [Test Keys]() | WIP | Create a special `test` key that can run tests next to the code |  |
+| [URL Inputs]() | WIP | Accept generic URLs for inputs |  |
+| [Hook Instantiation]() | WIP | Open the concept of using methods on instantiated hooks |  |
+| [Filters / Pipe Operators]() | WIP | Allow for jinja / bash style filters / pipes |  |
+| [Typed Macros]() | WIP | Allow creation of macros from within tackle files |  |
+| [Async Hook Calls]() | WIP | Add async functionality to the parser |  |
+| [Self Hook]() | WIP | Create a special `self` hook to reference the hook's methods during parsing |  |
+| [Native Providers in Individual Repos]() | WIP | Move the majority of the providers to remote locations |  |
+| [Structured File Hook Shared Functions]() | Considering | Update all the structured file hooks (ie yaml, json, toml, and ini) to have shared functions. |  |
+| [Hook Field Validators]() | Implemented | Validate fields with custom logic similar to pydantic's validation |  |
+| [Hooks Dir as Base]() | Implemented | Allow the base of a provider be either a hooks dir or tackle file |  |
+| [Return Key]() | WIP | Create a special key for returning the value when parsing |  |
+| [Pre / Post Context]() | Implemented | Break up the context into pre and post hook parsing groups of data to allow importing hooks |  |
+| [Context Composition]() | Implemented | Changing core context from inheritance based object to composition |  |
+| [Pydantic 2.0 Upgrade]() | Implemented | Upgrade to pydantic version 2.0 |  |
+| [Hook Field Defaults]() | Implemented | Allow flexible ways to declare hook field defaults |  |
+| [Splat Operators]() | Implemented | Allow splat operators to instantiate hooks - ie `a_hook **a_dict` or `a_hook *a_list` | [ast-parser]()<br />[peg-parser]()<br /> |
+| [Hook Access Modifiers]() | Implemented | Make hooks either public or private allowing distinction for what is in `tackle <target> help`. |  |
+| [Private + Bare `exec` Method (ie `exec<_` / `exec`)]() | WIP | None |  |
+| [Complex Types]() | Implemented | Declaring hooks as types |  |
+| [Overrides Improvements]() | WIP | Improve how overrides are tracked and applied when parsing files / hooks |  |
+| [Path Tracking]() | WIP | Modify how paths are tracked and made available through special variables. |  |
+| [Command Arrow]() | WIP | Add macro to easily call commands on different platforms |  |
+| [AST Upgrade]() | WIP | Upgrade string parsers to use an AST | [context-composition]()<br /> |
+| [Loop Variable Update]() | Implemented | Improve the loop parsing logic to allow declaring variables, ie `i in a_list`. |  |
+| [Base Methods as Hooks]() | WIP | Allow base methods to be called directly as hooks |  |
+| [Remote Provider Cache]() | WIP | Create a cache for remote providers to minimize network calls to git on ever provider import |  |
+| [Method Properties]() | WIP | Methods could have properties which inform their behaviour |  |
 
 [//]: # (--end--)
 
-
-### Status
-
-Implemented
-Accepted
-WIP
-Rejected
-Deferred
-Abandoned
-
-## Not implemented
-
-In GH issue
-
+> Table generated with Tackle

proposals/ast-parser.md

@@ -13,13 +13,9 @@ blockers:
 
 Upgrade string parsers to use an AST
 
-- Proposal Status: [WIP](README.md)
-- Issue Number: [1](https://github.com/sudoblockio/tackle/issue/1)
-- Blockers:
-  - [Context Composition](https://github.com/sudoblockio/tackle/issue/1)
-
+- Proposal Status: [wip](README.md#status)
+- Issue Number: [172](https://github.com/sudoblockio/tackle/issue/172)
 ---
-
 [//]: # (--end-header--start-body--MODIFY)
 
 Current parsing is based on regex which works in most use cases but has become:

proposals/async.md

@@ -8,10 +8,15 @@ blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
-
 # Async Hook Calls
 
+Add async functionality to the parser
+
+- Proposal Status: [wip](README.md#status)
+- Issue Number: [226](https://github.com/sudoblockio/tackle/issue/226)
+---
+[//]: # (--end-header--start-body--MODIFY)
+
 Would be cool to implement async functionality but would need another arrow to define the hook as being awaitable.
 
 ```yaml

proposals/base-methods-as-hooks.md

@@ -8,11 +8,14 @@ blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
+# Base Methods as Hooks
 
-# Proposal: Default Methods as Hooks
+Allow base methods to be called directly as hooks
 
-> Status: Not Implemented
+- Proposal Status: [wip](README.md#status)
+- Issue Number: [233](https://github.com/sudoblockio/tackle/issue/233)
+---
+[//]: # (--end-header--start-body--MODIFY)
 
 This proposal would allow setting literal values if the first arg is a default method - either `if`, `else`, `when`, or `for`. All other kwargs fail.
 

proposals/command-arrow.md

@@ -8,11 +8,14 @@ blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
-
 # Command Arrow
 
-> Status: Not implemented
+Add macro to easily call commands on different platforms
+
+- Proposal Status: [wip](README.md#status)
+- Issue Number: [227](https://github.com/sudoblockio/tackle/issue/227)
+---
+[//]: # (--end-header--start-body--MODIFY)
 
 It is very common to want to run a system command which tackle should make simple. Issue is the parser and general mechanics are not very elegant right now. Solution should be clean to make it on par with being able to create a Makefile.
 

proposals/complex-type-use.md

@@ -9,10 +9,15 @@ blockers: []
 
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
-
 # Complex Type Use
 
+Using complex types has issues
+
+- Proposal Status: [wip](README.md#status)
+- Issue Number: [228](https://github.com/sudoblockio/tackle/issue/228)
+---
+[//]: # (--end-header--start-body--MODIFY)
+
 Currently we allow declaring types for fields within a declarative hook and can have those fields validated when the hook is called but can't create fields which are validated on assignment. This prevents creation of typed data types like `list[str]` or `list[Foo]` within a hook.  
 
 ### Examples

proposals/complex-types.md

@@ -8,10 +8,14 @@ blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
+# Complex Types
 
+Declaring hooks as types
 
-# Complex Types
+- Proposal Status: [implemented](README.md#status)
+- Issue Number: [229](https://github.com/sudoblockio/tackle/issue/229)
+---
+[//]: # (--end-header--start-body--MODIFY)
 
 Would be good if a declarative hook field was able to be typed like another hook would be. This would allow nesting of typed structures as is common in many schema oriented operations.
 

proposals/context-composition.md

@@ -8,11 +8,14 @@ blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
-
 # Context Composition
 
-> Status: WIP
+Changing core context from inheritance based object to composition
+
+- Proposal Status: [implemented](README.md#status)
+- Issue Number: [230](https://github.com/sudoblockio/tackle/issue/230)
+---
+[//]: # (--end-header--start-body--MODIFY)
 
 This proposal would be for refactoring the core context object from an inheritance to a composition based approach. Would have broad implications across the entire stack. This is some long standing technical debt that needs to be paid at some point.  
 

proposals/declarative-hook-config.md

@@ -17,11 +17,6 @@ Allow hooks to have a model_config parameter exposing pydantic config params
 ---
 [//]: # (--end-header--start-body--MODIFY)
 
-
-# Declarative Hook Config
-
-> Status: WIP
-
 We should be able to customize the config on a declarative hook since it is possible with a python hook. For this though, we need to worry about order of operations as:  
 
 1. The config is normally set on the base hook so we'll need to override that

proposals/default-hook.md

@@ -10,17 +10,13 @@ blockers: []
 
 # Default Hook
 
-Allow files to have a default hook to be called
+Allow files to have a default hook to be called when no arguments are supplied
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [232](https://github.com/sudoblockio/tackle/issue/232)
 ---
 [//]: # (--end-header--start-body--MODIFY)
 
-# Default Hook
-
-> Status: Implemented
-
 Currently, there is no way to call a tackle file without an argument and have any kind of exposed schema which would lend itself to building a defined schema that could be rendered into a help screen. This proposal aims at defining that default interface so that
 
 ### Questions

proposals/exec-method-arrows.md

@@ -1,17 +1,22 @@
 ---
 id:
-title: Exec Method Arrows
+title: Private + Bare `exec` Method (ie `exec<_` / `exec`)
 status: wip
 description:
 issue_num: 248
 blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
-
 # Private + Bare `exec` Method (ie `exec<_` / `exec`)
 
+None
+
+- Proposal Status: [wip](README.md#status)
+- Issue Number: [248](https://github.com/sudoblockio/tackle/issue/248)
+---
+[//]: # (--end-header--start-body--MODIFY)
+
 The `exec` method on a declarative hook is special in that when it exists, the return of the hook is public data from parsing it. This is how we can make dcl hooks into functions with typed inputs. For example:
 
 ```yaml

proposals/hook-access-modifiers.md

@@ -8,11 +8,14 @@ blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
-[//]: # (--end-header--start-body--MODIFY)
+# Hook Access Modifiers
 
-# Access Modifiers
+Make hooks either public or private allowing distinction for what is in `tackle <target> help`.
 
-> Status: Implemented
+- Proposal Status: [implemented](README.md#status)
+- Issue Number: [235](https://github.com/sudoblockio/tackle/issue/235)
+---
+[//]: # (--end-header--start-body--MODIFY)
 
 Hooks right now are all in the same namespace but if they are to be used as interfaces / rendered into help, they need to be namespaced in a way that allows collections of hooks to be exposed and others to remain hidden. The natural way to do this would be in allowing hooks with different signs to play a role in different
 

proposals/hook-alias.md

@@ -8,6 +8,13 @@ blockers: []
 ---
 [//]: # (--start-header--DO NOT MODIFY)
 
+# Hook Alias
+
+Alias hooks so they can be called easier
+
+- Proposal Status: [wip](README.md#status)
+- Issue Number: [236](https://github.com/sudoblockio/tackle/issue/236)
+---
 [//]: # (--end-header--start-body--MODIFY)
 
 Would be nice to be able to define aliases for a hook to make them easier to call. For instance the `listdir` hook could additionally be called with `list_dir` or `dir_list`: