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

[Fix] --help command #884

Merged
merged 8 commits into from
Aug 23, 2022
Merged

[Fix] --help command #884

merged 8 commits into from
Aug 23, 2022

Conversation

camfairchild
Copy link
Collaborator

This PR:

  • fixes the btcli --help output
  • adds a test to verify the help output is correct
  • modifies the help output with the version

@camfairchild camfairchild added the bug Something isn't working label Aug 18, 2022
Copy link
Contributor

@Eugene-hu Eugene-hu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation looks good, but we just need to be very careful about the config class. Let's run a few tests on nobunaga to make sure nothing breaks :)

bittensor/_axon/__init__.py Show resolved Hide resolved
@@ -37,13 +40,15 @@ class InvalidConfigFile(Exception):
""" In place of YAMLError
"""

def __new__( cls, parser: ArgumentParser = None, strict: bool = False ):
def __new__( cls, parser: ArgumentParser = None, strict: bool = False, args: Optional[List[str]] = None ):
Copy link
Contributor

@Eugene-hu Eugene-hu Aug 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for this change? I will be hesitant to change the base config class unless necessary. Every single bittensor object initiates a base config object. So ideally, we should keep it as lightweight as possible. The config class is just a whole bag of worms XD

Copy link
Contributor

@Eugene-hu Eugene-hu Aug 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also think the config class is in need of a cleanup, so it might be good for the next update.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is an inversion of control of the sys.argv from the command line.

Normally argparser gets it internally, if you don't specify which args to parse, by calling sys.argv the same way I added in the neuron __main__

I added it as an optional arg and lower down it defaults to calling sys.argv if None, so the class will function as normal without the arg specified.

The IoC is important for testing if btcli --help works correctly and has the text we expect. Otherwise I would have to patch argparser, which is subject to API changes. This is recommended from some SO posts I read.

Edited: dep injection -> IoC

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this sounds like a temporary change before the cleanup, i would generate some issues in this repository to not forget about the tech debt we have around this code.

Copy link
Contributor

@eduardogr eduardogr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not know much this codebase, but from my point of view this change seems simple enough to be able to merge it.
It looks direct and effective with its purpose.

I understand that changing functions' interfaces is not the best and can bring chaos to the codebase.

I would like that before we close this PR we create issues tagged as tech-debt exposing the debt we have related with CLI/Config/Args. Because, from my point of view, seems like the bug was also introduced for the existence of the tech-spec.

Finally, since this is going to the nobunaga branch and with no release deadline I see we can merge this and continue learning and improving the codebase from this point if something fails again. By the way, we should have the necessary test coverage for this, do we have it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants