gtalarico/pipenv-pipes

A PipEnv Environment Switcher

Pipes

Pipenv Environment Switcher ⚡

       :alt: Codecov

---

Overview

Pipes is a Pipenv companion CLI tool that provides a quick way to jump between your pipenv powered projects.

Documentation

Documentation is hosted on pipenv-pipes.readthedocs.io

License

MIT License

Credits

Package created with Cookiecutter + cookiecutter-pypackage

Author

Send me a message on twitter

pipenv-pipes's Issues

Shell Competion

Description

It would be very nice to have Shell Completion, like virtualenvwrapper!

What I Did

I made a small script that runs on BASH and ZSH.

$ cat pipenv-pipes-completion.sh

# Shell completion for pipenv-pipes

export BASE_SHELL=$(basename $SHELL)
export DEFAULT_HOME="$HOME/.virtualenvs"

if [[ "$BASE_SHELL" == "zsh" ]] ; then
  autoload bashcompinit && bashcompinit
fi

_pipenv-pipes_completions() {
  COMPREPLY=($(compgen -W "$(ls $DEFAULT_HOME $PIPENV_HOME)" -- "${COMP_WORDS[1]}"))
}

complete -F _pipenv-pipes_completions pipes

$ source ./pipenv-pipes-completion.sh
$ pipes <tab><tab>

What do you think about it? Could we put somewhere in the code base or maybe as a script some where and put the activation instructions on README?

Cheers,

Completion commands default error message

Describe the bug
The shell completion code introduced in #10 (and at https://github.com/gtalarico/pipenv-pipes/pull/11/files#diff-3aa7be69f7648738d9c6d40f0b79a305R57) doesn't account for the case in which no environment has been created yet.

In that situation, the code snippet splice the default return message of pipes and propose each word as if it was a project.

To Reproduce
Steps to reproduce the behavior:

1. rm -rf $WORKON_HOME

2. $ _pipenv-pipes_completions() {
   > COMPREPLY=($(compgen -W "$(pipes --_completion)" -- "${COMP_WORDS[1]}"))
   > }
   $ complete -F _pipenv-pipes_completions pipes
   $ pipes <TAB>
   ~/.virtualenvs  environments             in                       
   No                       found                    pipenv                   

Expected behavior
Instead of:

$ pipes --_completion
No pipenv environments found in ~/.virtualenvs

I guess the --_completion option should returns nothing when $WORKON_HOME is empty.

Environment:

• OS: macOS 10.13
• Pipes Version: pipenv-pipes==0.6.2

Add Curses

Wolud be nice to support for curses selection.

There is a working example in this branch:

Todo

• Check Windows Compat with branch curses-picker. Might need windows binaries
• Port + Patch Picker
• Add Color Support
• Add option to disable and fall back

Curses Windows Support Resources

Python Doc
Windows Wheels

asciimatics

Create env feature

I hope I'm not the only one who switches between environments by navigating to my project directories (.env). So the most often usecase is to create an environment.

virualenvwrapper has the feature to create env and connect it with a project dir.

Have you any plans to deliver such sort of action to your project?

Thanks.

P.S. Nice job, thank you for your work!

Shell Completion OpenBSD (pd)ksh

On OpenBSD, we've by default the pdksh.

To have a shell completion, write into your personal "~/.profile":

# after the call of exported environments variables for your Python, as WORKON_HOME.
set -A complete_pipes -- $(pipes --_completion)

Restart your session or a new terminal ;)

Deletion of Environments

Is your feature request related to a problem? Please describe.
It would be great if we can delete envs directly from Pipes

Describe the solution you'd like
A key combination to trigger a deletion prompt i.e. yes/no/okay/cancel
Pipenvs are not particularly important as they can be recreated rather easily so accidental deletions is not that big of a deal.

Describe alternatives you've considered
Doing it manually, not feasible for large number of envs.

pipes activation does not cd to venv .project path

Describe the bug
From docs:

"This would cd into directory /path/to/project1 and activate the corresponding Pipenv Shell."

in the section:
https://pipenv-pipes.readthedocs.io/en/latest/usage.html#from-the-command-line

To Reproduce

1. Use pipenv install to create new venv in ~/code/path/proj1 (sample shown below)
2. In that project dir, type pipes --link ., success: Project Directory Set.
3. cd /some/where/else/
4. pipes -v proj1

Expected behavior
The docs say that pipes will cd into the project directory and then activate it.
It activates it, but then I'm in my $HOME directory, as happens when using cd and have no path arg following.
It does show the "Project Directory" correctly, which is in the .project file within the pipenv --venv folder as expected.... but doens't cd to it at all.

Screenshots
--list

--verbose envname

Environment:

• OS: Darwin Kernel Version 18.5.0
• Pipes Version: 0.7.1
• Shell: Bash v5.0

Tests + Travis CI is broken

Test Framework needs to mock a few pipenv environments so
cli can be called properly. Currently, Travis is broken because the instance does not find local pipenv environments

• Unit tests for all functions

picker directory missing from wheel pypi distribution

• Pipenv Pipes version: pipenv_pipes-0.5.0-py2.py3-none-any.whl (8.4 kB)
• Python version: python3.6
• Operating System: linux, ubuntu

Description

Can't run pipes because of an import error.

I installed pipenv_pipes from with pip. Using the command:

$ pip3 install pipenv-pipes --user

When I run pipes, the package can't import picker. This is because the installation has no picker subdirectory. I looked at the .whl and there is no picker included in the .whl. I think something in the build process must have skipped this directory.

Output showing problem

$pipes

Traceback (most recent call last):
  File "/home/me/.local/bin/pipes", line 7, in <module>
    from pipenv_pipes.cli import pipes
  File "/home/me/.local/lib/python3.5/site-packages/pipenv_pipes/cli.py", line 10, in <module>
    from .picker import Picker
ImportError: No module named 'pipenv_pipes.picker'

So looking at the sitepackage directory, there is no picker subdir

$cd .local/lib/python3.5/site-packages/pipenv_pipes/
$cd ls
cli.py  core.py  environment.py  __init__.py  pipenv.py  __pycache__/  utils.py

Having a look at the contents of .whl, picker is missing:

$pwd
/pipenv_pipes-0.5.0-py2.py3-none-any.whl_FILES
$ls pipenv_pipes/
cli.py  core.py  environment.py  __init__.py  pipenv.py  utils.py

Improve Env <> Project Linking

Pipenv is able to locate the environment location for a given project directory using the folder path and hash, but not the other way around (I think...?)

In other words, given a pipenv Environment folder (eg. ~.local/share/virtualenvs/project1-12345678),
there is no way of knowing what is the corresponding project directory.

It is possible, however, from a given Project Directory, to resolve the corresponding environment location - if there is one.
Let's say the environment above was create from the location: ~/dev/project1.
From this directory, a user could run: pipenv --venv, and the output would be:

~.local/share/virtualenvs/project1-12345678

(if pipenv --venv is run from a directory with no corresponding venv, the output is:

No virtualenv has been created for this project yet!

For Pipes to work properly and be able to to Activate AND cd into the project directory (similar to workon), we currently need the user to manually create this "link", and this is done as following:

1. From ~/dev/project1, user creates a new pipenv environment by running pipenv install
2. A new enviroment is created by pipenv: ~.local/share/virtualenvs/project1-12345678
3. User runs: Pipes --link .
4. Behind the scenes, Pipes will run pipenv --venv from the current location (.), and the result will be: ~.local/share/virtualenvs/project1-12345678
5. The command output is written into a file ~.local/share/virtualenvs/project1-12345678/.project
6. The .project file will help Pipes know what directory to cd into.
7. User runs pipes project1
8. Pipes resolves the environment by name, and looks for a .project file *
9. If present, it cds into that directory, and activates the env shell.
   * If a .project file is not present, use needs to perform step 3.

Solution

--link step #3 above should be removed entirely.

For this to happen, we need to have pipenv store the project location into the environment it creates.
Virtualenvwrapper does that by storing a .project. The project path is set manually by the useer (setprojectdir .)

With pipenv that should be even easier than for virtualenvwraper, since the enviroment is always create FROM within the project directory.
All we would need to do is save that location inside the enviroment in a .project file.

Related PR:
pypa/pipenv#1861
@meshy @uranusjr

Tests fail with weird error if python2 is not installed

Describe the bug
Pipes does not require Python 2 to operate. It should not require it for tests, but at present the tests do not pass unless it is installed.

To Reproduce

• Make sure there is no system python2 executable available
• Run pytest

Expected behavior
The tests should pass

Actual behaviour
Tests fail with an error like the following:

___________ ERROR at setup of TestFindEnvironments.test_find_binary ____________

request = <FixtureRequest for <Function 'test_find_binary'>>

    def fill(request):
        item = request._pyfuncitem
        fixturenames = item.fixturenames
        autousenames = item.session._fixturemanager._getautousenames(item.nodeid)
    
        for fname in fixturenames:
            if fname not in item.funcargs and fname in autousenames:
                item.funcargs[fname] = request.getfixturevalue(fname)
    
        if hasattr(item, 'callspec'):
            for param, val in sorted_by_dependency(item.callspec.params, fixturenames):
                if is_lazy_fixture(val):
                    item.callspec.params[param] = request.getfixturevalue(val.name)
    
>       _fillfixtures()

/usr/lib/python3/dist-packages/pytest_lazyfixture.py:40: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tests/conftest.py:129: in mock_env_home
    envs = find_environments(pipenv_home)
pipenv_pipes/core.py:33: in find_environments
    binpath = find_binary(envpath)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

envpath = '/tmp/pipenv_home_real0cjax3c0/proj1-7PMzaxDr'

    def find_binary(envpath):
        """ Finds the python binary in a given environment path """
        env_ls = os.listdir(envpath)
        if 'bin' in env_ls:
            binpath = os.path.join(envpath, 'bin', 'python')
        elif 'Scripts' in env_ls:
            binpath = os.path.join(envpath, 'Scripts', 'python.exe')
        else:
            raise EnvironmentError(
>               'could not find python binary path: {}'.format(envpath))
E           OSError: could not find python binary path: /tmp/pipenv_home_real0cjax3c0/proj1-7PMzaxDr

pipenv_pipes/core.py:52: OSError
________ ERROR at setup of TestFindEnvironments.test_get_python_version ________

request = <FixtureRequest for <Function 'test_get_python_version'>>

    def fill(request):
        item = request._pyfuncitem
        fixturenames = item.fixturenames
        autousenames = item.session._fixturemanager._getautousenames(item.nodeid)
    
        for fname in fixturenames:
            if fname not in item.funcargs and fname in autousenames:
                item.funcargs[fname] = request.getfixturevalue(fname)
    
        if hasattr(item, 'callspec'):
            for param, val in sorted_by_dependency(item.callspec.params, fixturenames):
                if is_lazy_fixture(val):
                    item.callspec.params[param] = request.getfixturevalue(val.name)
    
>       _fillfixtures()

/usr/lib/python3/dist-packages/pytest_lazyfixture.py:40: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tests/conftest.py:129: in mock_env_home
    envs = find_environments(pipenv_home)
pipenv_pipes/core.py:33: in find_environments
    binpath = find_binary(envpath)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

envpath = '/tmp/pipenv_home_realeeyf2spo/proj1-AJFfG1vO'

    def find_binary(envpath):
        """ Finds the python binary in a given environment path """
        env_ls = os.listdir(envpath)
        if 'bin' in env_ls:
            binpath = os.path.join(envpath, 'bin', 'python')
        elif 'Scripts' in env_ls:
            binpath = os.path.join(envpath, 'Scripts', 'python.exe')
        else:
            raise EnvironmentError(
>               'could not find python binary path: {}'.format(envpath))
E           OSError: could not find python binary path: /tmp/pipenv_home_realeeyf2spo/proj1-AJFfG1vO

pipenv_pipes/core.py:52: OSError

After a bit of digging, I managed to trace the problem to the virtualenv creation. The virtualenv command is failing, but because it outputs to stdout the error is being ignored (aside: it would be a good idea to check the error code here instead of just stderr). Then conftest tries to continue without a virtualenv, leading to the error pasted above.

Environment:

• OS: Debian sid

Add Black Formatter

Add Better example for Linking Envs Directory

D:\Dropbox\shared\dev\repos
λ pipes genome
Pipenv enviroment 'genome-1AY1GkYk' does not have project directory.
Use 'pipes --link <project-dir>' to link a project directorywith this enviroment

D:\Dropbox\shared\dev\repos
λ cd genome

D:\Dropbox\shared\dev\repos\genome (dev/main -> origin)
λ pipes --link .
Target Project Directory is: D:\Dropbox\shared\dev\repos\genome
Looking for associated Pipenv Environment...
Environment is: C:\Users\gtalarico\.env\genome-1AY1GkYk
Set Project Directory + Environment association? [y/N]: y

Project Direectory Set.

Subshell starts and immediately exits

Describe the bug
When I launch pipes from Commander, the subshell launches and immediately terminates.

To Reproduce
Steps to reproduce the behavior:
type pipes into cli

Expected behavior
The subshell should launch an interactive console for the virtual environments

Screenshots

Environment:

• OS: Windows 10
• Pipes Version 0.7.1
• Curses 2.2

Additional context