Package: envy
# envy [![Build Status](https://travis-ci.org/shaunvxc/envy.svg?branch=master)](https://travis-ci.org/shaunvxc/envy) [![PyPI version](https://badge.fury.io/py/envy.svg)](https://badge.fury.io/py/envy)### 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.envyis a utility that allows you to**safely**interact with all of the site-packagesin your currently activevirtualenvas if they were in yourcurrent working directory.![envy_best5](https://cloud.githubusercontent.com/assets/3979753/13486757/df564a3a-e0e1-11e5-9e48-666fb658f6f4.gif)### How?
Let’s say you are working in a virtual environment for a projectfoobut are getting errors thrown from one offoo’s depedencies– a library calledbar.  The stacktrace tells us the error was thrown frombaz.py.  Usingenvy, simply run (from anywhere in your file system):(foo)$ envy edit bar/baz.pyand 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 withenvy, there is no need!  Before launching the editor,envyfirst creates a backup of the package in~/.envies/foo/bar.Environment safe from corruption, you can confidentally throw down somepdbbreakpoints,printstatements, or any little hack you want!   Whenever you are ready torestore the package back to it’s original state, you need only run:(foo)$ envy clean barAnd it’ll be like you were never there!### Wait, there’s more! :pig2: :egg:Say you maintain a libraryham, as well as another projecteggsthat depends onham.  You want to test out some of your recent changes toham, but are far from ready to start messing with the versioning or runningsetup.py install. Withenvyyou can very quickly sync the changes from your local dev copy ofhamto the one that liveseggsvirtual environment like so:(eggs)$ envy sync hamYou can also sync indivual files:(eggs)$ envy sync ham/spam.py*Note:*envy synccommands must be run from within your local copy of the package you are syncing (i.e.ham)As withenvy 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/any-file.py####Discard any and all edits and returnany-site-packageto its original state:(active-virtualenv)$ envy clean any-site-packageYou can run botheditandcleanfrom 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 fromrandom_libto where it lives insome-virtualenv:(some-virtualenv):dev/random_lib$ envy sync random_libFor the time being,synccommands cannot be run as flexibly aseditandclean(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 edituses the$EDITORenvironment varible to launch a text editor– if this is not set, simply add:export EDITOR=your_editor_of_choiceto your.bashrcfile.##Installation$ pip install envyFor manual installation:`shell $ git clonehttps://github.com/shaunvxc/envy.git$ cd envy $ python setup.py install `##Future work:
- add aenvy difffunction to compare currently applied changes with the clean, backed-up copy
- Explore the option of packaging in a diff. format (installation withcurl), in order for it to be available globally (rather than on a pervirtualenvbasis)
- handle egg-named locally built packages? or enforce local building with pip instead?
- allowsyncto 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 (https://github.com/shaunvxc/envy/fork)
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