Tab complete settable attribute values

[bambu]

It would be nice to have the ability to tab complete settable attribute values. The use case i have is there is a setting that takes a string and I would like the user to complete from a generated list of available options.

While I could create a custom command for this and have the completion that way, it seems kinda hackish and I would have to reimplement the same thing for any other future settings where the answer is not a True/False, numeric value, or arbitrary string.

[tleonhardt]

@bambu Thanks for the suggestion. I agree that this would be nice. This isn't a trivial change, but should be doable. We will have to discuss the design for the best way to do this.

If you have a good idea for how to implement this in a maintainable fashion, then please feel free to submit a PR.

[kotfu]

I have many ideas for improvements to the settings in cmd2 and this is another great addition to the list, but I think this should probably wait for after 1.0.

[tleonhardt]

The only reason I was thinking of doing this before 1.0 is that there is a high probability it might involve changes which break existing cmd2 applications that alter self.settable.

[kotfu]

@tleonhardt I agree with you that I don't think this change can be done without breaking existing apps which alter self.settable. So the question becomes, are we going to add yet another breaking change before 1.0, or will we postpone this for after 1.0?

[kmvanbrunt]

@tleonhardt @kotfu
The last couple of years have seen these major enhancements (forgive me if I forgot some):

• @tleonhardt got it working in Python 3 and has made numerous enhancements and bug fixes
• @kotfu rewrote the parser and added argparse integration
• I worked on tab completion
• @anselor integrated tab completion and argparse via the AutoCompleter
• We worked together to rewrite history and pyscript functionatiliy

Since @tleonhardt became maintainer, a very talented core group has come together to give cmd2 an amazing overhaul. The settable feature is really the only thing we haven't touched. I say why not just do it before 1.0? Otherwise we risk maintaining a 1.0 and 2.0 branch very early into 1.0's lifetime.

With that, I have an idea that #870 and this issue could be solved by using argparse. It already has validation for basic types and it's easy to add custom validation functions. Additionally, cmd2 added tab completion to it. I don't have all of it fleshed out, but I'm sure it's doable.

Thoughts?

[tleonhardt]

I really don't know what would be better for cmd2 developers (i.e. our customers) - to get 1.0 out sooner with less breaking changes, likely followed up by 2.0 with breaking changes in short order or to make another breaking change prior to 1.0.

In general, I think it might be best to "rip the bandaid off" and make the change now if this can be done quickly. However, we've been dragging our feet getting the 1.0 release out and if getting this breaking change in now significantly delays the 1.0 release that probably wouldn't be a good thing.

@kmvanbrunt Can you elaborate on your idea that this could be solved by using argparse? Doing so doesn't seem obvious to me. But as you mention argparse has great support for validation and our integration with it extends it to have great support for tab-completion, so if there is a good way to do this it might be a clean and easy win.

[kotfu]

I'm supportive as long as this is the last breaking change we do before releasing 1.0. The reason all projects who use us are pinned to a specific version is because every new release we make has a breaking change. Let's change this settable thing, and then no more.

[tleonhardt]

@kotfu Agreed, there have been a ton of breaking changes lately and for the health of the project we very much need to slow down and stabilize. So after this last change, lets finish up the documentation and put out a 1.0 release.

[kmvanbrunt]

@kotfu Thanks for allowing this last change. I agree to introduce no more breaking changes before 1.0.

I pushed up a branch called set_update which adds tab completion to the set command values.

[kotfu]

I like it. I suggest that the next release we cut is called 1.0.0-rc1 or something similar to indicate we intend no more breaking changes, just bug fixes and documentation updates.

[tleonhardt]

I like the suggestion of making the release have some sort of special version number, but how standard is it to use things like -rc1 after the numbers? Will that work well with pip, setuptools_scm, etc.?

[kotfu]

I dunno. I did a little digging, and PEP 440 says it's allowed if we do 1.0.0rc1