chore: update proposals header format

proposals/.tackle.yaml

@@ -1,3 +1,21 @@
+(help='Update all issues')<-:
+  Update proposals->: update_proposals
+  Update Readme->: update_readme
+
+update_proposals()<-:
+  loop over 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
+      issue_number: "{{p.issue_num}}"
+      title: "{{p.title}}"
+      body: "{{body}}"
+      status: "{{p.status}}"
+
 Proposal<_:
   file: str
   id:
@@ -34,6 +52,9 @@ get_proposals()<_:
     for: f in files
     frontmatter->: markdown_frontmatter {{f}}
     append proposal->: append output "{{Proposal(file=f, **frontmatter)}}" --if frontmatter!={}
+  sort output:
+    ->: sort output
+    keys: ['status']
   return->: output
 
 get_github_token()<_:
@@ -76,7 +97,10 @@ update_header(p Proposal)<-:
 
     - Proposal Status: [{{p.status}}](README.md#status)
     - Issue Number: [{{p.issue_num}}](https://github.com/sudoblockio/tackle/issue/{{p.issue_num}})
-    ---
+    - Proposal Doc: [{{p.file}}](https://github.com/sudoblockio/tackle/blob/main/proposals/{{p.file}})
+
+    ### Overview
+
   body->: update_section {{p.file}} {{var(header_tpl)}} start-header end-header
 
 update_readme()<-:
@@ -95,24 +119,6 @@ update_readme()<-:
     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%} |
+      {% for p in proposals|selectattr("WIP") %}| [{{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:
-    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
-        issue_number: "{{p.issue_num}}"
-        title: "{{p.title}}"
-        body: "{{body}}"
-        status: "{{p.status}}"
-
-    Update Readmes->: update_readme

proposals/ast-parser.md

@@ -15,7 +15,9 @@ Upgrade string parsers to use an AST
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [172](https://github.com/sudoblockio/tackle/issue/172)
----
+- Proposal Doc: [ast-parser.md](https://github.com/sudoblockio/tackle/blob/main/proposals/ast-parser.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Current parsing is based on regex which works in most use cases but has become:

proposals/async.md

@@ -14,7 +14,9 @@ Add async functionality to the parser
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [226](https://github.com/sudoblockio/tackle/issue/226)
----
+- Proposal Doc: [async.md](https://github.com/sudoblockio/tackle/blob/main/proposals/async.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Would be cool to implement async functionality but would need another arrow to define the hook as being awaitable.

proposals/base-methods-as-hooks.md

@@ -14,7 +14,9 @@ Allow base methods to be called directly as hooks
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [233](https://github.com/sudoblockio/tackle/issue/233)
----
+- Proposal Doc: [base-methods-as-hooks.md](https://github.com/sudoblockio/tackle/blob/main/proposals/base-methods-as-hooks.md)
+
+### Overview
 [//]: # (--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

@@ -14,7 +14,9 @@ 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)
----
+- Proposal Doc: [command-arrow.md](https://github.com/sudoblockio/tackle/blob/main/proposals/command-arrow.md)
+
+### Overview
 [//]: # (--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

@@ -15,7 +15,9 @@ Using complex types has issues
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [228](https://github.com/sudoblockio/tackle/issue/228)
----
+- Proposal Doc: [complex-type-use.md](https://github.com/sudoblockio/tackle/blob/main/proposals/complex-type-use.md)
+
+### Overview
 [//]: # (--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.  

proposals/complex-types.md

@@ -14,7 +14,9 @@ Declaring hooks as types
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [229](https://github.com/sudoblockio/tackle/issue/229)
----
+- Proposal Doc: [complex-types.md](https://github.com/sudoblockio/tackle/blob/main/proposals/complex-types.md)
+
+### Overview
 [//]: # (--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

@@ -14,7 +14,9 @@ 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)
----
+- Proposal Doc: [context-composition.md](https://github.com/sudoblockio/tackle/blob/main/proposals/context-composition.md)
+
+### Overview
 [//]: # (--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

@@ -14,7 +14,9 @@ Allow hooks to have a model_config parameter exposing pydantic config params
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [231](https://github.com/sudoblockio/tackle/issue/231)
----
+- Proposal Doc: [declarative-hook-config.md](https://github.com/sudoblockio/tackle/blob/main/proposals/declarative-hook-config.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 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:  

proposals/default-hook.md

@@ -14,7 +14,9 @@ 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)
----
+- Proposal Doc: [default-hook.md](https://github.com/sudoblockio/tackle/blob/main/proposals/default-hook.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 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

proposals/exec-method-arrows.md

@@ -14,7 +14,9 @@ None
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [248](https://github.com/sudoblockio/tackle/issue/248)
----
+- Proposal Doc: [exec-method-arrows.md](https://github.com/sudoblockio/tackle/blob/main/proposals/exec-method-arrows.md)
+
+### Overview
 [//]: # (--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:

proposals/hook-access-modifiers.md

@@ -14,7 +14,9 @@ Make hooks either public or private allowing distinction for what is in `tackle
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [235](https://github.com/sudoblockio/tackle/issue/235)
----
+- Proposal Doc: [hook-access-modifiers.md](https://github.com/sudoblockio/tackle/blob/main/proposals/hook-access-modifiers.md)
+
+### Overview
 [//]: # (--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

@@ -14,7 +14,9 @@ Alias hooks so they can be called easier
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [236](https://github.com/sudoblockio/tackle/issue/236)
----
+- Proposal Doc: [hook-alias.md](https://github.com/sudoblockio/tackle/blob/main/proposals/hook-alias.md)
+
+### Overview
 [//]: # (--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`:

proposals/hook-field-defaults.md

@@ -14,7 +14,9 @@ Allow flexible ways to declare hook field defaults
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [237](https://github.com/sudoblockio/tackle/issue/237)
----
+- Proposal Doc: [hook-field-defaults.md](https://github.com/sudoblockio/tackle/blob/main/proposals/hook-field-defaults.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Declarative hook default values should be parsed for hook calls.

proposals/hook-field-validators.md

@@ -14,7 +14,9 @@ Validate fields with custom logic similar to pydantic's validation
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [241](https://github.com/sudoblockio/tackle/issue/241)
----
+- Proposal Doc: [hook-field-validators.md](https://github.com/sudoblockio/tackle/blob/main/proposals/hook-field-validators.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 ## Examples

proposals/hook-instantiation.md

@@ -14,7 +14,9 @@ Open the concept of using methods on instantiated hooks
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [238](https://github.com/sudoblockio/tackle/issue/238)
----
+- Proposal Doc: [hook-instantiation.md](https://github.com/sudoblockio/tackle/blob/main/proposals/hook-instantiation.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 When calling methods, in the past we have opted for converging the fields of method into the base like this.

proposals/hook-methods.md

@@ -14,7 +14,9 @@ Allow creating hooks within hooks that act like methods with parameter inheritan
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [239](https://github.com/sudoblockio/tackle/issue/239)
----
+- Proposal Doc: [hook-methods.md](https://github.com/sudoblockio/tackle/blob/main/proposals/hook-methods.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Right now the order of operations for how to run and access a hook method is all messed up and needs to be rebuilt. Current there are two places where methods can be called, 1, within a tackle file and 2, from command line. Ideally they should be converged.

proposals/hooks-dir-as-base.md

@@ -14,7 +14,9 @@ Allow the base of a provider be either a hooks dir or tackle file
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [240](https://github.com/sudoblockio/tackle/issue/240)
----
+- Proposal Doc: [hooks-dir-as-base.md](https://github.com/sudoblockio/tackle/blob/main/proposals/hooks-dir-as-base.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 When there is no tackle file in a directory, it would be appropriate to instead check if there is a hooks dir as well since if there was a tackle file, then those hooks in the hooks dir would also be parsed.

proposals/loop-variable-update.md

@@ -14,7 +14,9 @@ Improve the loop parsing logic to allow declaring variables, ie `i in a_list`.
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [234](https://github.com/sudoblockio/tackle/issue/234)
----
+- Proposal Doc: [loop-variable-update.md](https://github.com/sudoblockio/tackle/blob/main/proposals/loop-variable-update.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Currently the loop logic inserts temporary variables `item` and `index` into the context so that they are available for rendering but this results in overlapping variables in embedded loops. What would be better is if we supported inserting the variable as part of the `for` key with `var_name in a_list` and similar semantics. Would require overhauling the parser some custom tokenizer.

proposals/method-properties.md

@@ -14,7 +14,9 @@ Methods could have properties which inform their behaviour
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [242](https://github.com/sudoblockio/tackle/issue/242)
----
+- Proposal Doc: [method-properties.md](https://github.com/sudoblockio/tackle/blob/main/proposals/method-properties.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 It would be helpful if we could expose the control of how methods operated with parameters such as:

proposals/overrides-improvements.md

@@ -14,7 +14,9 @@ Improve how overrides are tracked and applied when parsing files / hooks
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [247](https://github.com/sudoblockio/tackle/issue/247)
----
+- Proposal Doc: [overrides-improvements.md](https://github.com/sudoblockio/tackle/blob/main/proposals/overrides-improvements.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Overrides are needed for testing as input fields need values inserted for testing.

proposals/path-tracking.md

@@ -14,7 +14,9 @@ Modify how paths are tracked and made available through special variables.
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [244](https://github.com/sudoblockio/tackle/issue/244)
----
+- Proposal Doc: [path-tracking.md](https://github.com/sudoblockio/tackle/blob/main/proposals/path-tracking.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 There is some ambiguity about what the current directory is. Current logic is

proposals/peg-parser.md

@@ -14,7 +14,9 @@ Change the parser from regex to PEG
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [246](https://github.com/sudoblockio/tackle/issue/246)
----
+- Proposal Doc: [peg-parser.md](https://github.com/sudoblockio/tackle/blob/main/proposals/peg-parser.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 The parser isn't very good now and should be overhauled. This was always the plan but the current regex based approach was sufficient to continue at the time.  

proposals/pipe-operators.md

@@ -14,7 +14,9 @@ Allow for jinja / bash style filters / pipes
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [249](https://github.com/sudoblockio/tackle/issue/249)
----
+- Proposal Doc: [pipe-operators.md](https://github.com/sudoblockio/tackle/blob/main/proposals/pipe-operators.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 ```yaml

proposals/pre-post-context.md

@@ -14,7 +14,9 @@ Break up the context into pre and post hook parsing groups of data to allow impo
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [251](https://github.com/sudoblockio/tackle/issue/251)
----
+- Proposal Doc: [pre-post-context.md](https://github.com/sudoblockio/tackle/blob/main/proposals/pre-post-context.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Right now all context outside of a declarative hook call is called after the declarative hook is executed. This sort of goes against how a typical program would be structured where definitions outside of a function are called by means of importing the module. In tackle, it would be nice if the parsing of that context was optional to have called before a function is imported. Since order of the function and the context makes the most sense to inform what context is parsed before the function is called vs after, this proposal suggests breaking up the parsing into these two sections.

proposals/provider-reorg.md

@@ -14,7 +14,9 @@ Reorganize the providers into logical groups
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [252](https://github.com/sudoblockio/tackle/issue/252)
----
+- Proposal Doc: [provider-reorg.md](https://github.com/sudoblockio/tackle/blob/main/proposals/provider-reorg.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 ## New Provider List

proposals/pydantic-2-upgrade.md

@@ -14,7 +14,9 @@ Upgrade to pydantic version 2.0
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [253](https://github.com/sudoblockio/tackle/issue/253)
----
+- Proposal Doc: [pydantic-2-upgrade.md](https://github.com/sudoblockio/tackle/blob/main/proposals/pydantic-2-upgrade.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 - Custom Field

proposals/remote-providers-cache.md

@@ -14,7 +14,9 @@ Create a cache for remote providers to minimize network calls to git on ever pro
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [255](https://github.com/sudoblockio/tackle/issue/255)
----
+- Proposal Doc: [remote-providers-cache.md](https://github.com/sudoblockio/tackle/blob/main/proposals/remote-providers-cache.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 ### Cache Path

proposals/remote-providers.md

@@ -14,7 +14,9 @@ Move the majority of the providers to remote locations
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [254](https://github.com/sudoblockio/tackle/issue/254)
----
+- Proposal Doc: [remote-providers.md](https://github.com/sudoblockio/tackle/blob/main/proposals/remote-providers.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 Over time the intention will likely be to move most of the native providers to a version controlled repo that is imported. Before doing this, we need to implement a better caching strategy for how providers are pulled in at startup.

proposals/reserved-fields.md

@@ -14,7 +14,9 @@ Change the syntax of reserved fields to reduce potential conflicts
 
 - Proposal Status: [wip](README.md#status)
 - Issue Number: [243](https://github.com/sudoblockio/tackle/issue/243)
----
+- Proposal Doc: [reserved-fields.md](https://github.com/sudoblockio/tackle/blob/main/proposals/reserved-fields.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 

proposals/return-hook.md

@@ -14,7 +14,9 @@ None
 
 - Proposal Status: [implemented](README.md#status)
 - Issue Number: [256](https://github.com/sudoblockio/tackle/issue/256)
----
+- Proposal Doc: [return-hook.md](https://github.com/sudoblockio/tackle/blob/main/proposals/return-hook.md)
+
+### Overview
 [//]: # (--end-header--start-body--MODIFY)
 
 > NOTE: See [return-key](return-key.md) for an additional macro for ergonomics.