Skip to content

Improve book-keeping on which Tool methods should be considered "usually bespoke" #1316

@nathanjmcdougall

Description

@nathanjmcdougall

Only two Tool methods do not provide a default implementation: .print_how_to_use() and the .name property.

When subclassing a tool, it's not always obvious which methods need over-ridden, compared to which ones provided nicely abstracted defaults, like is_used. Of course, any tool implementation is free to over-ride any default method. But for some of them, we expect it as a matter of course - e.g. get_dev_deps and default_command. It would be good to have some formal separation for these.

The ultimate objective is #856: to provide easy guidance on how to add new tools. But I don't want to hard-code a list of methods in the CONTRIBUTING.md file. I would much prefer to have some structural demarcation in the code, but this will need some design. Perhaps related to #1315.

Metadata

Metadata

Labels

documentationImprovements or additions to documentationinternalChanges to the internals without changing interfaces

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions