The default imports in __init__ causes significant lag

[anselor]

I have a module where I hijack argcomplete's bash completion and tie it into the completion function provided by AutoCompleter. Since AutoCompleter is a part of Cmd2 and __init__ imports Cmd and a bunch of other things, it causes about half a second lag on my machine to perform tab completion in bash. If I comment out all of the imports in __init__ there is no noticeable lag.

Since the next release is going to have a number of big changes anyway, I'm proposing we take out the default imports and force everyone to update their code to import from cmd2.cmd2. What do you guys think?

@tleonhardt @kmvanbrunt @kotfu

[tleonhardt]

If it is just one or two of the default imports in __init__.py which are causing the slowness I would prefer to keep some of them.

In the long run, I think minimizing the number of default imports is a great thing and we should do that. But in the short run, if we could minimize the impact to backwards compatibility it might be beneficial to many end users. Then again, maybe we should just rip the bandaid off?

But if you don't mind doing a little testing to see if getting rid of one or two of the imports could help, that would be a good thing.

[anselor]

Unfortunately it's the import of cmd2.Cmd that causes the lag. If we remove cmd2.Cmd from the default imports we may as well remove all of them.

[kotfu]

Still formulating an opinion here, but the good news is that in the ply branch, where we no longer import pyparsing, importing cmd2 takes about 60% as long as it does on the master branch.

[tleonhardt]

I have no problem taking out the default import of cmd2.Cmd since that is typically only used once per application. Thus no matter how a developer using cmd2 choses to approach fixing the backwards incompatibility this presents for them, it will only be a 1 line of code change.

For some of the other default imports, they are typically used many times. While there would be a smart way to fix the backwards incompatibility which would only require a single line of code change, if they don't take the smart approach they could be changing a lot of code.

Actually, I'm fine with removing almost all of the default imports from __init__.py. The only ones I kinda want to leave there are the two argparse decorators and the argument list decorator.

[tleonhardt]

@anselor
I'd say go ahead and put in your PR where you make this change and include a demo example showing the use of the argparse auto-completion at the bash command line via the aid of cmd2. This does sound like a really nice capability. I can just be a curmudgeon sometimes when it comes to backward incompatibility ...

I've loved everything else you have done, so I believe there is a high probability that I will love this too.

There will probably be numerous small changes required within the unit test and example code to deal with the default imports no longer being present.

[kmvanbrunt]

I've seen the argcomplete/AutoCompleter module and it is very cool, so naturally I support removing the imports. Basically it gives you AutoCompleter in bash when typing arguments for a cmd2-based app.

I also understand how annoying it is for developers to have compatibility issues each time a new version of software comes out. Perhaps we should make 0.9.0 a release candidate version since it will incorporate so many new features. That will give developers time to update their code and us time to debug the new stuff. After we know its stable, we can release the final version as 1.0.0.

Thoughts?

[tleonhardt]

I think it will be sufficient to just put big bold warnings in the release notes for 0.9.0 which mention the ways in which backwards compatibility has been broken - no need to call it a "release candidate" or anything like that.

Historically, all of the 0.x.0 releases of cmd2 have involved large changes including backwards incompatibilities. So I think if there are backwards incompatible changes we would like to make, then making several together in the 0.9.0 release is probably better than making one every release.

Better to make the changes we want now and hopefully gradually stabilize once we approach a 1.0.0 release.

[anselor]

It's worth noting that the argcomplete hijacking technically doesn't require your cli to be a cmd2 app. I've isolated it from cmd2 such that you should be able to use it to use the AutoCompleter tab completion in bash for any script that uses argparse. It may make sense to split out AutoCompleter separately and borrow the bash script and installation that argcomplete uses.

[tleonhardt]

I see some utility in leaving it within cmd2, that way you can use the same library to assist with creating both non-interactive command line utilities (CLU) and interactive command line applications (CLI).

[anselor]

argcomplete uses the Apache2 license and we're on MIT license here. I don't know how compatible the 2 licenses are.