Running `pipenv --completion` is very slow

Running pipenv --completion is consistently slow (it takes about 1 second to run), even after the command has been run multiple times and everything has been loaded into memory.

This means including eval $(pipenv --completion) in a .bashrc file makes the user wait for a second until the shell prompt comes up.

Describe your environment

1. OS: Kubuntu 17.04
2. Python version: 2.7.13
3. Pipenv version: 9.0.1

My shell is bash.

Expected result

The command shouldn’t take so long to run.

Actual result

When running in bash, the command takes a whole second to run.

$ time pipenv --completion

_pipenv_completion() {
    local IFS=$'\t'
    COMPREPLY=( $( env COMP_WORDS="${COMP_WORDS[*]}" \
                   COMP_CWORD=$COMP_CWORD \
                   _PIPENV_COMPLETE=complete-bash $1 ) )
    return 0
}

complete -F _pipenv_completion -o default pipenv


real    0m0.987s
user    0m0.888s
sys     0m0.080s

Steps to replicate

Run time pipenv --completion in a bash shell.

P.S. This is a great project.

[eli-schwartz]

@eli-schwartz click handles much of the overhead so it saves us from having to be experts on this specific thing most of the time

Yes, but I sort of wish click generated proper completions. 😃 There are tools which generate “proper” completions thereby saving every application developer the effort of knowing how it works, while still not recursively calling the tool itself for every little thing.

Anyway, not understanding how to write completions is one thing, not knowing how to install them is another.

@eli-schwartz though this doesn’t stay up-to-date when you upgrade. i have far too many things in my completions to remember to re-export their completion script every time up upgrade.

But it does. The current completion simply executes pipenv every time you try to complete anything; this doesn’t need to be checked for updates to the completion definition…

Either way it does not stop the completion from being delivered in data_files to share/bash-completion/completions, which should work, and be upgraded, whether installed via sudo pip (😢), pip install --user (since https://github.com/scop/bash-completion/commit/1d25d72ca8633c19cb089dff447d08c531379c59 it will be loaded from ~/.local), or python setup.py install --root="$package_manager_install_root". (It will not work for wheels, in which case oh well, you’re certainly not worse off than if you didn’t use data_files at all. Also IMHO wheels suck.)

This would save on one initial call to pipenv on every single new interactive shell, which while not quite as significant as one call on every single pipenv <TAB> is still not insignificant. It’s why bash-completion created the idea of lazy-loaded completions and tries to encourage people to use that over the “COMPAT_DIR” in /etc/bash_completion.d.

you should not assume that people don’t know much at all about thing x. it’s better to assume that their workflow, use-case, or tolerance is different to yours.

In the ideal case, users do not know, because it is automagically handled by developers or distro packagers. For example, https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/python-pipenv&id=484eec9eabad806654fea29801577dc2cbe4188a

…

At the very least, put your eval thing into the lazy-load directory, so it doesn’t execute on every single new shell init but only gets executed the first time you try to tab-complete this specific tool.

[Djaler]

Also, even 0.4s is so slow.