This is a pre-production deployment of Warehouse. Changes made here affect the production instance of PyPI (
Help us improve Python packaging - Donate today!

safely and easily debug files deep in python virtualenvs

Project Description

# envy [![Build Status](]( [![PyPI version](](

### Why?

Ever needed to look at some code living in one of your virtual environments? And then spent a good 3 or 4 seconds typing out the path? At which point you were weary about making changes/setting breakpoints in your site-packages without first creating a backup… which then needed to be restored again after testing, and yada yada yada. This workflow is annoying and tedious.

envy is a utility that allows you to **safely** interact with all of the site-packages in your currently active virtualenv as if they were in your current working directory.


### How? Let’s say you are working in a virtual environment for a project foo but are getting errors thrown from one of foo’s depedencies– a library called bar. The stacktrace tells us the error was thrown from Using envy, simply run (from anywhere in your file system):

(foo)$ envy edit bar/

and you’ll instantly be looking at the point-of-error from your favorite text editor!

##### Great, the file is open, but I shouldn’t create a backup before editing a file in my site-packages? :confused: This is a good practice, but with envy, there is no need! Before launching the editor, envy first creates a backup of the package in ~/.envies/foo/bar.

Environment safe from corruption, you can confidentally throw down some pdb breakpoints, print statements, or any little hack you want! Whenever you are ready to restore the package back to it’s original state, you need only run:

(foo)$ envy clean bar

And it’ll be like you were never there!

### Wait, there’s more! :pig2: :egg:

Say you maintain a library ham, as well as another project eggs that depends on ham. You want to test out some of your recent changes to ham, but are far from ready to start messing with the versioning or running install. With envy you can very quickly sync the changes from your local dev copy of ham to the one that lives eggs virtual environment like so:

(eggs)$ envy sync ham

You can also sync indivual files:

(eggs)$ envy sync ham/

*Note:* envy sync commands must be run from within your local copy of the package you are syncing (i.e. ham)

As with envy edit, an backup of the package’s (ham’s) state will be created automatically. As with before, to restore the original state:

(eggs)$ envy clean ham

## No talk, straight usage :no_mouth:

####Edit any file from any site-package installed in your active virtual environment:

(active-virtualenv)$ envy edit any-site-package/

####Discard any and all edits and return any-site-package to its original state:

(active-virtualenv)$ envy clean any-site-package

You can run both edit and clean from anywhere in your filesystem, as long as you are in a virtualenv that contains the package you ask it for.

####Restore all edited packages to their original state:

(active-virtualenv)$ envy clean –all

####Sync all local changes from random_lib to where it lives in some-virtualenv:

(some-virtualenv):dev/random_lib$ envy sync random_lib

For the time being, sync commands cannot be run as flexibly as edit and clean (they will only work when run from within the python package you wish to sync)- although it would certainly be possible to improve this in the future.

####View the differences between the current copy of a package and its backed up (clean) copy:

(some-virtualenv):$ envy diff package

*Note:* envy edit uses the $EDITOR environment varible to launch a text editor– if this is not set, simply add:

export EDITOR=your_editor_of_choice

to your .bashrc file.

##Installation $ pip install envy

For manual installation: `shell $ git clone $ cd envy $ python install `

##Future work: - add a envy diff function to compare currently applied changes with the clean, backed-up copy - Explore the option of packaging in a diff. format (installation with curl), in order for it to be available globally (rather than on a per virtualenv basis) - handle egg-named locally built packages? or enforce local building with pip instead? - allow sync to be run from anywhere on filesystem (would likely require an env-var like $DEV_SRC) - improve test coverage - add optional virtualenv argument to allow syncing/editing to nonactive virtualenvs

## Contributing 1. Fork it ( ) 1. Create your feature branch (git checkout -b new-feature) 1. Commit your changes (git commit -am ‘Add some feature’) 1. Run the tests (make test) 1. Push change to the branch (git push origin new-feature) 1. Create a Pull Request

Release History

Release History

This version
History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


History Node


Download Files

Download Files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

File Name & Checksum SHA256 Checksum Help Version File Type Upload Date
envy-0.2.0.tar.gz (9.4 kB) Copy SHA256 Checksum SHA256 Source Jul 13, 2016

Supported By

WebFaction WebFaction Technical Writing Elastic Elastic Search Pingdom Pingdom Monitoring Dyn Dyn DNS Sentry Sentry Error Logging CloudAMQP CloudAMQP RabbitMQ Heroku Heroku PaaS Kabu Creative Kabu Creative UX & Design Fastly Fastly CDN DigiCert DigiCert EV Certificate Rackspace Rackspace Cloud Servers DreamHost DreamHost Log Hosting