Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Determine right way of inheriting fields from the base in declarative hook methods #91

Open
robcxyz opened this issue Oct 8, 2022 · 0 comments

Comments

@robcxyz
Copy link
Collaborator

robcxyz commented Oct 8, 2022

Right now we are by default inheriting fields from the parent in declarative hooks. For instance in this hook:

<-:
  foo: bar 
  a_method<-:
    exec: 
      p->: print {{foo}}

It works to call tackle a_method but this raises the question if this should be enabled by default which I think makes sense. It could potentially have a key to disable inheritance or do it selectively but this is up for opinions that can be settled later.

This was initially prompted by the help screen as for a bit, we were rendering the foo kwarg in the help for the a_method. In the unpack_hook function in help.py, we have this condition to render these vars as by the time this has reached the parser, it has already been instantiated.

        elif isinstance(hook_field, dict):
            help_arg = HelpInput(name=i, **hook_field)
        elif isinstance(hook_field, ModelField):
            # If enabling inheritance for base vars in to the help, then this will
            # need to be active.
            # help_arg = HelpInput(
            #     name=i,
            #     type=hook_field.type_.__name__,
            #     # description=hook_field.d  # TODO: Fix this
            # )
            continue
        else:
            raise NotImplementedError

Right now it is disabled as I think this should be something that is toggleable but I don't really know what the right way to do that is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant