kislyuk / argcomplete Goto Github PK

If you have nargs > 1 and you want to have different choices for each arg, you have to use a custom action (see http://stackoverflow.com/q/8624034/161801). It would be nice to have some way to still complete in that case, so that it doesn't complete the wrong thing for the wrong argument.

On unique completion possibilities, a trailing space is added. This has the nice effect of adding a space on the command line, but is not an ideal way to do so. zsh, for instance, is smart enough to notice that trailing space, and keeps escaping it automatically (so instead of '--help', zsh completes it as '--help\ ' which is incorrect).

IMHO, this is better handled by removing the '-o nospace' in:

complete -o nospace -o default -F _python_argcomplete "t"

...and removing these lines:

in init.py:

 If there's only one completion, and it's not open-quoted and doesn't end with a continuation char, add a space
 continuation_chars = '=/:'
if len(completions) == 1 and completions[0][-1] not in continuation_chars:
    if cword_prequote == '' and not completions[0].endswith(' '):
        completions[0] += ' '

Is there any reason not to do so that I'm not seeing?

I noticed that when you install a package with setuptools using developement mode the easy-install script has a different "signature": EASY-INSTALL-DEV-SCRIPT

I don't see any good reason to not support it.

To reproduce it go in your argcomplete source directory and run:

$ ./setup.py develop
$ grep EASY $(which register-python-argcomplete)
# EASY-INSTALL-DEV-SCRIPT: 'argcomplete==0.5.9','register-python-argcomplete'

Pyenv is a very powerful Python version management written in bash.

argcomplete is incompatible with pyenv and any other program which make use of bash wrappers due to its use of COMP_WORDBREAKS variable.

COMP_WORDBREAKS is special and have a different behavior of other variables. Bash never read it from the parent environment and also reset it to unexported status.

The practical effect is that the COMP_WORDBREAKS variable set in _python_argcomplete function in register-python-argcomplete output never reach the environment of the invoked program if python executable is wrapped with a bash script.

To show this behavior simply run

$ COMP_WORDBREAKS=xxx bash -c 'printf "BASH_ENV=%q\nPYTHON_ENV=" "$COMP_WORDBREAKS"; python -c "import os;print os.environ[\"COMP_WORDBREAKS\"]"'
BASH_ENV=$' \t\n"\'@><=;|&(:'
PYTHON_ENV=Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/UserDict.py", line 23, in __getitem__
    raise KeyError(key)
KeyError: 'COMP_WORDBREAKS'

initial testing while converting py.test to use argparse and optionally use argcomplete indicates that argcomplete works on python2.6

I am not sure what testing should be involved to officially support this.

One thing to consider is to change setup.py so that argcomplete depends on argparse (which needs to be installed separately for 2.6). Although a program that works on 2.6
will probably have this dependency as well it is better to make this dependency explicit for argcomplete as well.

When using sudo I get no autocompletion despite getting autocompletion for other commands (eg. git).
Autocompletion works when running directly as root.

Tested on Ubuntu 12.04.3 LTS

$ example.py <TAB>
-h                                 --help

$ sudo example.py <TAB>

$ sudo git <TAB>
add                 bundle              credential-cache    format-patch        lg                  notes               request-pull        stash 
am                  checkout            credential-store    fsck                log                 pull                reset               status 
annotate            cherry              describe            gc                  lol                 push                revert              submodule 
apply               cherry-pick         df                  get-tar-commit-id   lola                rebase              rm                  tag 
archive             ci                  diff                grep                ls                  reflog              shortlog            whatchanged 
bisect              clean               difftool            help                merge               relink              show                
blame               clone               fetch               imap-send           mergetool           remote              show-branch         
br                  commit              filter-branch       init                mv                  repack              st                  
branch              config              flow                instaweb            name-rev            replace             stage 

# example.py <TAB>
-h                                 --help

Example Code

#!/usr/bin/env python
# PYTHON_ARGCOMPLETE_OK
import argparse
import argcomplete

parser = argparse.ArgumentParser()
argcomplete.autocomplete(parser)
args = vars(parser.parse_args())

Just something I've been pondering, food for thought, exchanging ideas, has this crossed your minds perhaps?

Would it be completely out of scope, too much to ask for, totally far fetched or rather does it make sense and be a benefit to everyone if we include completion for setup.py.

I can't help but think there's something missing, this project could easily be that magic bullet that simply covers all python completion requirements. We already have close knit integration with disttools but is that going far enough or should be go the extra mile. Without fixing setup.py it would always seem a incomplete, leave you wanting, not completely satisfying. It does not have to be that way.

If we agree that this is something we want, I can think of two viable approaches.

1. Hack argcomplete to take special care for config.py even though it does not employ argparse.
   This may simply involve the bash completion script required to facilitate this functionality at should be straight forward to compile.
2. Fix disttools to use argparse instead
   A patch to disttools is probably the most forward thinking of the two options, it will solve the incompatibility issues and we will be able to use argcomplete as is as well as removing duplication of implementation since argparse is a std library it makes sense that all standard libraries use it too.

What are your thoughts on this? Is this something we care for? Which is the desired solution and is this something we can realise in the not so distant future? How would you even go about changing a standard library, would this require a PEP et al? Anyone we know that knows this process?

Is there some way to tell argcomplete that command subcommand for any subcommand that isn't explicitly a subparser of argparse calls out to command-subcommand? We use this as a plugin architecture (similar to git).

I was not able to get completions under python 3.3 for py.test. Tracked this down to
python-argcomplete-check-easy-install-script throwing an Error:

(3_3_2)anthon@athlon64:~/src/argcomplete$ scripts/python-argcomplete-check-easy-install-script $(which tox) --verbose
Traceback (most recent call last):
File "scripts/python-argcomplete-check-easy-install-script", line 41, in
filename = pkgutil.get_loader(module_name).filename
AttributeError: 'SourceFileLoader' object has no attribute 'filename'

In 2.7.5 get_loader returns an pkgutil.ImpLoader instance in 3.3.2 this is an _frozen_importlib.SourceFileLoader

Instead of .filename the method .get_filename() should be used, this also solves issue #34 !!

With this program:

#!/usr/bin/env python
import argparse
import argcomplete
parser = argparse.ArgumentParser()
parser.add_argument("--get", action="store_true")
argcomplete.autocomplete(parser)
args = parser.parse_args()

The tab completion behaves differently when there are one vs. two blank spaces on the command line before pressing tab:

$ ./test.py␣<tab>
--get --help -h
$ ./test.py␣␣<tab>
(lists files in the current directory)

Minor issue and hopefully an easy fix.

argcomplete 0.6.9 don't work with setuptools 2.0.1 ??

.
.
.
.
running install
running build
running build_py
creating build
creating build/lib
creating build/lib/argcomplete
copying argcomplete/init.py -> build/lib/argcomplete
copying argcomplete/completers.py -> build/lib/argcomplete
copying argcomplete/my_argparse.py -> build/lib/argcomplete
copying argcomplete/my_shlex.py -> build/lib/argcomplete
running egg_info
writing argcomplete.egg-info/PKG-INFO
writing top-level names to argcomplete.egg-info/top_level.txt
writing dependency_links to argcomplete.egg-info/dependency_links.txt
reading manifest file 'argcomplete.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'argcomplete.egg-info/SOURCES.txt'
creating build/lib/argcomplete/bash_completion.d
copying argcomplete/bash_completion.d/python-argcomplete.sh -> build/lib/argcomplete/bash_completion.d
running build_scripts
creating build/scripts-2.7
copying and adjusting scripts/register-python-argcomplete -> build/scripts-2.7
copying and adjusting scripts/activate-global-python-argcomplete -> build/scripts-2.7
copying and adjusting scripts/python-argcomplete-check-easy-install-script -> build/scripts-2.7
changing mode of build/scripts-2.7/register-python-argcomplete from 644 to 755
changing mode of build/scripts-2.7/activate-global-python-argcomplete from 644 to 755
changing mode of build/scripts-2.7/python-argcomplete-check-easy-install-script from 644 to 755
running install_lib
creating /tmp/SBo/package-argcomplete/usr
creating /tmp/SBo/package-argcomplete/usr/lib64
creating /tmp/SBo/package-argcomplete/usr/lib64/python2.7
creating /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages
creating /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete
copying build/lib/argcomplete/init.py -> /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete
copying build/lib/argcomplete/completers.py -> /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete
copying build/lib/argcomplete/my_argparse.py -> /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete
copying build/lib/argcomplete/my_shlex.py -> /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete
creating /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete/bash_completion.d
copying build/lib/argcomplete/bash_completion.d/python-argcomplete.sh -> /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete/bash_completion.d
byte-compiling /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete/init.py to init.pyc
byte-compiling /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete/completers.py to completers.pyc
byte-compiling /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete/my_argparse.py to my_argparse.pyc
byte-compiling /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete/my_shlex.py to my_shlex.pyc
running install_egg_info
Copying argcomplete.egg-info to /tmp/SBo/package-argcomplete/usr/lib64/python2.7/site-packages/argcomplete-0.6.9-py2.7.egg-info
running install_scripts
creating /tmp/SBo/package-argcomplete/usr/bin
copying build/scripts-2.7/register-python-argcomplete -> /tmp/SBo/package-argcomplete/usr/bin
copying build/scripts-2.7/activate-global-python-argcomplete -> /tmp/SBo/package-argcomplete/usr/bin
copying build/scripts-2.7/python-argcomplete-check-easy-install-script -> /tmp/SBo/package-argcomplete/usr/bin
changing mode of /tmp/SBo/package-argcomplete/usr/bin/register-python-argcomplete to 755
changing mode of /tmp/SBo/package-argcomplete/usr/bin/activate-global-python-argcomplete to 755
changing mode of /tmp/SBo/package-argcomplete/usr/bin/python-argcomplete-check-easy-install-script to 755
Traceback (most recent call last):
File "setup.py", line 4, in
from setuptools import setup, find_packages
ImportError: No module named 'setuptools'

When adding argcomplete to packages for which you did not write setup.py yourself, it is sometimes guesswork which file should be marked with PYTHON_ARGCOMPLETE_OK.

A --verbose option for python-argcomplete-check-easy-install-script
could give some helpful feedback

Argcomplete looks very nice, I'm going to plug it into Argh as the default solution for bash completion. The only problem I've encountered is that if a Python script is wrapped in a bash script as in the example below, something gets broken; the suggestions are displayed but you cannot choose between them, and hitting Enter pushes all of them through stdin.

~/bin/myscript.sh

#!/bin/bash
# PYTHON_ARGCOMPLETE_OK
~/src/my-awesome-script.py

...where my-awesome-script.py is the one from the docs.

It could be just a glitch in my own environment or me not knowing some peculiarities of bash, but anyway it would be nice to know what to fix and probably to have this documented.

Thanks for argcomplete!

In a argparse subparser, I have a positional argument with nargs="*". I get no completion for this argument when adding a ChoicesCompleter to the argument. If I change nargs to "+" I get completion.

Should I not get completion with nargs="*" for a positional argument?

Enable full REPL support by defining a readline completer driven entry point.

Without -o nospace (removed in #55), bash appends a space to directory completions at the end of the line.

I've just discovered that currently the argcomplete installs two modules instead of one:

$ mkdir tmp/
$ ./setup.py install --root tmp/
[...snip...]
$ ls tmp/usr/lib/python3.3/site-packages/
argcomplete  argcomplete-0.6.6-py3.3.egg-info  test

Obviously we don't need a system-wide module named "test" that belongs to another package.

I think find_packages() should get an argument. Didn't try: no time for that ATM.

Would it be possible to also support completions in fish? https://github.com/fish-shell/fish-shell

python 2.5 could probably be supported

Necessary changes:

• rewriting the print() statement
• using "from future import with_statement"

Perhaps I'm not understanding how to use this but I tried add

source /usr/local/etc/bash_completion.d/python-argcomplete.sh

into my ~/.bash_profile

But when I start a new shell I get:

bash: complete: -D: invalid option
complete: usage: complete [-abcdefgjksuv] [-pr] [-o option] [-A action] [-G globpat] [-W wordlist] [-P prefix] [-S suffix] [-X filterpat] [-F function] [-C command] [name ...]

My system:

peterbe@mpb:~$ bash --version
GNU bash, version 4.2.45(2)-release (i386-apple-darwin13.0.0)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

While implementing argcomplete for tox I noticed that
pkgutil.get_loader(module_name).filename
returned a directory as entry point.

This throws an error on opening, what should be opened is the 'init.py' file inside that directory.

I am not sure if there might be packages without .py in which case 'init.pyc' instead should be opened.

ken@ken:~$ ./weechat.py -h
Traceback (most recent call last):
File "./weechat.py", line 9, in
import argcomplete
ImportError: No module named 'argcomplete'

This is after I've installed argcomplete through pip.. and activated global completion

Input:

./issue20.py "blah<TAB>

The lexer returns:

PREFIX: '"blah' 
SUFFIX: '' 
WORDS: ['./issue20.py']

Figure out how to handle the quotes in these kinds of inputs.

Don't know if this is related to #51, but here it is:

#!/usr/bin/env python3

import argcomplete, argparse

parser = argparse.ArgumentParser(prog='acbug.py', description="bug test tool")

subparsers = parser.add_subparsers(title='subcommands', metavar='subcommand')
subparser_build = subparsers.add_parser('build')
subparser_build.add_argument('var', choices=['bus', 'car'])
subparser_build.add_argument('--profile', nargs=1)

argcomplete.autocomplete(parser)
args = parser.parse_args()

On doing:

./acbug.py build bus <tab>

Expected completions:
--profile

Actual completions:
bus car --profile

With this program:

#!/usr/bin/env python
import argparse
import argcomplete
def c_url(prefix, parsed_args, **kwargs):
    return [ "http://url1", "http://url2" ]
parser = argparse.ArgumentParser()
parser.add_argument("--url", help="URL").completer = c_url
argcomplete.autocomplete(parser)
args = parser.parse_args()

Argument --url requires a single non-option argument, but:

./test.py --url <tab>
expect: http://url1 http://url2
actual: --help --url -h http://url1 http://url2

python-argcomplete-check-easy-install-script should be run using the same interpreter as the wrapper itself, otherwise it may not find the target package (or find the wrong version) due to include path and version differences

I'm packaging argcomplete for Debian/Ubuntu

http://lists.debian.org/debian-devel/2013/01/msg00172.html

as it's required to have arg completion working in python programs that rely on argh module.

I've noticed argcomplete totally misses copyright information. The only information i can find is the license type in setup.py (Apache Software License)

To allow your package to enter linux distributions you should at least:

1. Include the full text of all licenses used in the top-level directory in the COPYING file.

http://wiki.debian.org/UpstreamGuide#Licenses

2. Please document copyright attribution in each file.

http://tieguy.org/blog/2012/03/17/on-the-importance-of-per-file-license-information/

Thanks,
Marco

When I install package python-argcomplete in Debian and then run activate-global-python-argcomplete as root, other types of completion stop working. I don't know if this issue occurs with packages for other distributions.

For example, activating argcomplete globally prevents completion of package names for apt-get when used like sudo apt-get install <Tab>, or completion for mplayer when only multimedia files are suggested as completion options. Instead of those custom completion types a common file list completion is being offered. At the same time Python completion with argcomplete is working as intended.

python-argcomplete package version is 0.3.3-1

EDIT:

The same occurs when installing the package with pip and then activating global completion.

I had to get argcomplete working on tcsh. I have a hack working. It would be great if it could get integrated properly into argcomplete. I'll work on this later if I can. I'm using tcsh 6.17.00. Here's what I do, to get an example called 'newcommand.py' working:

file: newcommand-complete.sh

#!/bin/sh
export IFS=''
export COMP_LINE=${COMMAND_LINE}
export COMP_WORDBREAKS=
export COMP_POINT=${#COMMAND_LINE}
export _ARGCOMPLETE=1
newcommand 8>&1 9>&2 1>/dev/null 2>/dev/null

On the command line or in .cshrc:

complete newcommand.py 'p@*@`newcommand-complete.sh`@'

Hi,

Thanks for great package! However, it took me a while to enable global argcomplete, since there's nowhere information about restarting bash :-)

In my case:
"
sudo pip install argcomplete
sudo activate-global-python-argcomplete
bash
"

Cheers,
Jovik

When having multiple sequential positional arguments, the completion for each subsequent argument (except the first) includes completions for the previous ones. Example below:

#!/usr/bin/env python3

import argcomplete, argparse

parser = argparse.ArgumentParser(prog='acbug.py', description="bug test tool")
parser.add_argument('var', choices=['bus', 'car'])
parser.add_argument('value', choices=['orange', 'apple'])

argcomplete.autocomplete(parser)
args = parser.parse_args()

./acbug.py <tab>
bus     car     -h      --help

Okay so far, but all subsequent autocompletes are buggy:

./acbug.py bus <tab>
apple   bus     car     -h      --help  orange

and:

./acbug.py bus orange 
apple   chair   -h      --help  orange  table 

etc. Am i missing something or is this a bug? I'm using Python 3.3.2. Thanks a whole bunch for argcomplete!

With this program:

#!/usr/bin/env python
import argparse
import argcomplete

def c_url(prefix, parsed_args, **kwargs):
    return [ "http://url1", "http://url2" ]

def c_get(prefix, parsed_args, **kwargs):
    return [ "get1", "get2" ]

def c_put(prefix, parsed_args, **kwargs):
    return [ ]

parser = argparse.ArgumentParser()
parser.add_argument("--url", help="URL").completer = c_url
sub = parser.add_subparsers()

get = sub.add_parser("get")
get.add_argument("filename").completer = c_get

put = sub.add_parser("put")
put.add_argument("filename").completer = c_put

argcomplete.autocomplete(parser)
args = parser.parse_args()

Arguments like --url show up after get and put, where they're not allowed:

./test.py get <tab>
expect: get1 get2
actual: --help --url -h get1 get2

./test.py put <tab>
expect: (no suggestions)
actual: --help --url -h

With the recent merge of distribute into setuptools, installing setuptools and then argcomplete failed for me. Is there any reason why argcomplete would depend on distribute? If not, removing it helps to avoid the installation problem.

Let me start by saying well done with all the improvements since v2.9 the README looks awesome I must make a point to look at the docs... but who reads manuals anyway? =)

Being the devils advocate again, even though I am well aware that the project clearly states BASH completion I know there are many who use zsh for whatever reasons unbeknown to myself, your friendly devil and scope-boundary-shifter extraordinaire.

From what I can source the differences are not that huge but I am not well versed on things that make you go Oh My at all, maybe someone with such astonishment afflictions would care to step up and explain yourselves or just enlighten us on the peculiarities of zsh completion as both would be fascinating to hear.

What I can add: There is something called bashcompinit as explained in man zshcompsys and reads as follows:

The function bashcompinit compatibility with bash's programmable completion system. When run it will define the functions, compgen and complete which correspond to the bash builtins with the same names. It will then be possible to use completion specifications and functions written for bash.

Would that suggest our work is done here or do we need something other (zstyle, compctl, worshiping of false devils perhaps)? None of which would make me jump with joy, being a jealous devil and all, just thought I'd stir the pot and see what's cooking.

nJoy!

Arbitrarily using 9 is causing me problems. The issue was tracked down to python using fd 9 to read a file for importing. Specifically, that file is argcomplete/init.py! This causes things to blow up with an error code that is very close to, but not quite, -(2^30).

An alternative way to do this would be to claim a new fd using bash, and put it in an environment variable before invoking the program. Then, check that env var and use it instead of 9. (or 8, presumably, for stdout).

I trying to write a script with various sub-commands that execute different actions. For example remote managing a server and debugging connectivity isssues or enable/disable services.

   server
       - test                 # sub-command 1
           - ping            # sub-sub-command 1.1
           - mtr             # sub-sub-command 1.2
       - config             # sub-command 2
           - apache       # sub-sub-commands 2.1
               - enable    # sub-sub-sub-commands 2.1.1
               - disable   # sub-sub-sub-command 2.1.2

What i would like to have is the auto-completion of all sub-*-commands so a user does not have to know all the sub-commands by heart.

Example usage woud be:

    server<space><TAB>
    test config            # auto-completion prints available sub-commands
    server test<space><TAB>
    ping mtr               # autocompletion prints test-sub-commands
    server test ping <servername>

The sub-commands shall not start with dashes as they are not actual switches. I guessing this could be done with a custom completer? So far i could not get argcomplete to auto-complete anything that has no dashes in it.

Can this be done with argcomplete?

Probably not possible in general but maybe print a message asking the user to do that manually.

It would be nice to have an option to not list aliases in the completion list. Many applications with rich command line interfaces (like svn) tend to liberally use aliases for subcommands. These are very useful as shortcuts (eg: svn list is same as svn ls) for advanced users. However, it's confusing and noisy when all these are listed as completions.

However, some times, listing aliases might be useful. For example, svn blame has {praise, annotate, ann} as aliases, and the user might want to see these.

So perhaps the ultimate solution is to allow for fine-grained control of listing aliases. But for now, what would be useful is a global "includeAliases = True/False" option passed to argcomplete.

(As a side note, zsh is again light years ahead of bash completion in this regard: it understands aliases.)

I would think this would be easy to accomplish, given that aliases to argparse are specified separately, but I might be mistaken.

With this test program:

#!/usr/bin/env python
import argparse
import argcomplete
def c_test(prefix, parsed_args, **kwargs):
    return [ "name1", "name2" ]
parser = argparse.ArgumentParser()
parser.add_argument("name").completer = c_test
exc = parser.add_mutually_exclusive_group()
exc.add_argument("--get", action="store_true")
exc.add_argument("--set", action="store_true")
argcomplete.autocomplete(parser)
args = parser.parse_args()

Usage is listed as:

usage: test.py [-h] [--get | --set] name

But optional arguments aren't suggested as completions, and completions for name are listed even after a name has been supplied.

Expected:

$ ./test.py <tab>
-h --get --set name1 name2
$ ./test.py --<tab>
--get --set
$ ./test.py --get <tab>
-h name1 name2
$ ./test.py --get name1 <tab>
-h

Actual:

$ ./test.py <tab>
name1 name2
$ ./test.py --<tab>
(nothing)
$ ./test.py --get <tab>
name1 name2
$ ./test.py --get name1 <tab>
name1 name2

First of all, thanks for this awesome piece of code!

I am attempting to convert an inconisistent set of sysadmin scripts which have evolved over the past 15 years in a semi-standard way, into a consistent set of scripts, aided with tab completion for appropriate parameters. The current nature of the scripts is that some or all of the parameters are positional (each non-postional parameter is explicitly asked for with a text prompt). Each positional parameter restricts the available options for further positional parameters, and I have managed to get this working correctly.

However, there is a minor annoyance. Is there a way to specifically exclude -h and --help from appearing as tab-completable options, while keeping them as valid options as far as argparse is concerned?

Looking at the code, I can't see a way of doing this currently, and I suspect it would involve changes to the money-patching code to be selective as to which subparsers get intercepted.

After running python setup.py develop, I don't get auto-completion because the script can't find the file correctly.

The problem seems to be that this line resolves incorrectly causing an IOError. get_metadata is resolving to files within the .egg-info directory. For example if my working directory is /Users/dcosson/my-package and I ran python setup.py develop from there, it resolves to /Users/dcosson/my-package/my_package.egg-info/scripts/myscript

I'm not too familiar with setuptools, so it's possible that I have misconfured something and the scripts should be getting copied into the egg-info folder.

I'm on OSX 10.9 and python 2.7.5

632dc9a fixes completions with :, but other chars in COMP_WORDBREAKS still don't work: "'@><=;|&(:

$ activate-global-python-argcomplete --user
usage: activate-global-python-argcomplete [-h] [--dest DEST] [--user]
activate-global-python-argcomplete: error: Path /home/marc/.bash_completion.d/ does not exist

Apparently I didn't have this directory. It would be nice if it was autocreated so that I didn't have to make it manually. Once I created the directory it worked fine.

Thanks!

When I executed following command,

$ activate-global-python-argcomplete --dest=- > ~/pycomplete

I got those followings error messages, I hope it can be helpful.

Traceback (most recent call last):
File "/Users/anrs/doucodes/dae/venv/bin/activate-global-python-argcomplete", line 28, in
with pkg_resources.resource_stream("argcomplete", "resources/python-argcomplete.sh") as in_fh:
File "/Users/anrs/doucodes/dae/venv/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg/pkg_resources.py", line 910, in resource_stream
self, resource_name
File "/Users/anrs/doucodes/dae/venv/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg/pkg_resources.py", line 1313, in get_resource_stream
return open(self._fn(self.module_path, resource_name), 'rb')
IOError: [Errno 2] No such file or directory: '/Users/anrs/doucodes/dae/venv/lib/python2.7/site-packages/argcomplete/resources/python-argcomplete.sh'

And I check your source codes on GitHub, I found no directory is called "resources"

Is Argcomplete compatible with Python 3?
If it isn't, are there any significant problems or simply lack of time/interest?

Please add argparse in install_requires variable. It will not hurt with python2.7 and will fix installation on python2.6.

You don't seem like the own dog food types, or am I mistaken?

I find it odd that the two scripts bundled with argcomplete namely

• register-python-argcomplete
• activate-global-python-argcomplete

Both suffer from a lack of autocompletion yet they both have arguments and both utilize argparse in particular so is there any reason why they don't have the argcomplete functionality?

I was actually hoping to find some real world examples specifically since these scripts would pose the same problems I am experiencing as mentioned in #4

#!/usr/bin/python
# EASY-INSTALL-SCRIPT: 'argcomplete==0.2.7','activate-global-python-argcomplete'
__requires__ = 'argcomplete==0.2.7'
import pkg_resources
pkg_resources.run_script('argcomplete==0.2.7', 'activate-global-python-argcomplete')

/usr/local/bin/activate-global-python-argcomplete lines 1-5 490 bytes

Do you see the predicament? It would also instill a sense that you have trust in your own product if you were actually using it yourselves. A list of projects that have adopted the solution might also be useful, what do you think?

You can expect a pull request shortly...

I noticed a while ago that when I source the script python-argcomplete.sh I cannot tab to complete environment variables. If I comment the last line in the script:

#complete -o default -D -F _python_argcomplete_global

Then I can do:

macbook-pro:~ jmlopez$ echo $PA<TAB>
macbook-pro:~ jmlopez$ echo $PATH

As soon as I activate the global completer then it doesn't do the environment variable completion anymore. This behavior does not happen when registering an awesome script, i.e.

eval "$(register-python-argcomplete my-awesome-script.py)"

Not sure if this is happening with others, can someone check if this is bug on argparse? I'm using bash 4.2:

macbook-pro:~ jmlopez$ echo $BASH_VERSION
4.2.45(2)-release

It is not clear how we are supposed to use the PYTHON_ARGCOMPLETE_OK token. Sure if I add it to a script file it works, but the which script which bash is looking at is the easyinstall wrapper script in the path. This does not automatically contain the required token so I guess we should find a way to get it there.

Trues Bob if I hack it in manually completion works like a charm!

#!/usr/bin/python
# EASY-INSTALL-SCRIPT: 'aero==0.0.1a2','aero'
# PYTHON_ARGCOMPLETE_OK
__requires__ = 'aero==0.0.1a2'
import pkg_resources
pkg_resources.run_script('aero==0.0.1a2', 'aero')

Any advice, words of wisdom or just a shoulder for me to cry on?

Tx for an awesome library, I originally had my own completion closely modeled around the solution implemented by pip itself. When aero revealed that there is a library I thought it a good idea to jump on the band wagon so to speak so I am in the process of sending my code to /dev/null but for that I need to at least get it sort of working, would you agree?

Keep up the good work!

#!/usr/bin/python
# PYTHON_ARGCOMPLETE_OK
import argparse
import argcomplete
parser = argparse.ArgumentParser()
subparsers = parser.add_subparsers(dest='command')
parser1 = subparsers.add_parser('local')
parser1.add_argument('name', choices=['zzz', 'aaa'])
parser2 = subparsers.add_parser('lookup')
parser2.add_argument('dest', choices=['a', 'b', 'c'])
sub2 = parser2.add_subparsers(dest='type')
parser3 = sub2.add_parser('env')
parser3.add_argument('name', choices=['zzz', 'aaa'])
parser4 = sub2.add_parser('etc')
parser4.add_argument('file', choices=['my.cnf', 'apache.conf'])

argcomplete.autocomplete(parser)
data = parser.parse_args()

If you go one subparser deep, into the local branch, this works as expected. Once you fill out zzz or aaa, you're no longer offered autocomplete choices.

$ ./testcase.py local zzz [tab][tab]
$

If you go into the lookup branch and hit the second subparser, the subparser choice is presented to you as many variables deep as you care to go.

e.g.

$ ./testcase.py lookup env env env [tab][tab]
env     etc     -h      --help 
$

Interestingly, if a non subparser argument is added before the inital one, you get offered the correct choices mostly (when you hit a,b,c you get env and etc in the options as well, if you pick a, b, or c completion works properly from then on, but if you choose etc or env, it goes back into looping forever).