shaunvxc / envy

:memo: safely make edits and sync local changes to files living in the site-packages of your virtualenvs
MIT License
39 stars 3 forks source link

Would be more useful as a system package #3

Open shaunvxc opened 8 years ago

shaunvxc commented 8 years ago

One problem with this package is that in order for it to work, it currently NEEDS to be run from a virtualenv.

On one hand, this makes sense as the package is not useful UNLESS you are currently IN a virtualenv.

However, it also means that it needs to be installed in each and every virtualenv for which you wish to use it.

It would be nice if it could be installed in the global site-packages and then used from all virtualenvs, but this is a problem because system packages are run using the system python. This is a problem because we currently use the following check to confirm the application is being run from a virtual_env:

def is_active_venv():
    if hasattr(sys, 'real_prefix'):
        return True

    if sys.prefix != getattr(sys, "base_prefix", sys.prefix):
        return True

    return False

Even when the user runs envy while in an active virtualenv, the system python runs envy, and therefore does not have a 'real_prefix' attribute.

Furthermore, we locate the module(s) to be edited or sych'd using imp.find_module-- this will also not work when run from a non-virtualenv installed python.

One possibility would be to pass in the optional path argument to imp.find_module and point it to $VIRTUAL_ENV or $WORKON_HOME if present-- but this won't handle all cases and could get messy. I'll keep thinking about this..

For now, it seems envy will simply need to be installed in the virtualenvs you wish to use it.

shaunvxc commented 8 years ago

Another possibility would be to write an installer script, and require installation through curl.

This would work because we could install the script in /usr/local/bin with a #/usr/bin/env python shebang at the top.

Basically it comes down to this:

Would being able to install once and run from any environment be worth making the package not pip-installable?

amitsaha commented 8 years ago

I would certainly like to be able to install envy once system-wide and be able to use it in all my virtual envs.

shaunvxc commented 8 years ago

Thanks for your interest! I have some ideas for this.

Given that envy is already on pypi, I might create a separate wrapper project that installs it globally (rather than removing it from pypi, etc).

Do you have any thoughts on a good way of doing this?