Make Python module recognize and auto-discover virtualenv environments, including those made by virtualenvwrapper.

[bitemyapp]

It currently can't find my dependencies. Nobody that uses Python professionally works outside of virtualenv.

[bitemyapp]

virtualenvwrapper uses ~/.virtualenv

[berdario]

There's already a discussion going on in this LT issue

[bitemyapp]

@berdario you don't need to necessarily specify it because there's a common location that 99% of virtualenvs made by virtualenvwrapper are put into.

[ibdknox]

That discussion should move here :)

[berdario]

@bitemyapp you need to specify it because you don't know the name of the virtualenv that the project is using (in theory, there could even be multiple environments for the same project, but this use case shouldn't concern LT since it's something that's handled by testing tools like Tox)

[bitemyapp]

@berdario hum, that's a good point but you could make an educated guess based on the name of the project you're inside of.

Given that, I'd lean towards just letting the user specify the virtualenv.

[berdario]

Guessing is surely not the most robust solution, but I agree: it would help to get 90% there...
how should the user specify the virtualenv?

workspace behavior seems the way to go, but they're really underdocumented... also: every time that I change workspace, everything that I wrote in workspace.behavior is lost

[jeffwidman]

I'm a bit of a n00b python guy, so still figuring things out, but it seems the ideal for me would be:

1. Within user.behavior, set default path for folder containing my virtualenvs so that I can later reference virtualenvs by just their name. Have this default path default to ~/.virtualenvs but let it be overridden if the user, like me, stores them elsewhere.

2. Within workspace.behavior, set a default virtualenv for that workspace:
   a) using just the virtualenv name if it resides within my virtualenv container folder, eg 'projectone'
   b) using the full path if the virtualenv lives outside the container folder, eg '~/code/projectone/virtualenv'

3. Optional: Occasionally I want to switch back and forth between different virtualenvs for a project, so somehow make it possible to choose a different virtualenv when launching the interpreter... maybe within 'Connections' > 'Python' > 'Enter for default, otherwise use arrow keys to select a different virtualenv'

[iluminite]

virtualenvwrapper uses $WORKON_HOME, so LT could also use this. but this path, ~.virtualenv/ is the HOME for many virtualenv. EG, if you open two projects in different virtualenvs, you open two separate python executables. LT needs to be smart about this.

[waynew]

I, for one, am particularly interested in this issue. I'm just getting started with lighttable, but I certainly like following the virtualenvwrapper conventions for convenience/portability. And alternatively specifying the interpreter to use.

[foobarbecue]

People like me are excited about using LightTable with Django, but LT is pretty useless for Django development until we can do this. Would be wonderful if I could tell the connection to run "manage.py shell" with a virtualenv enabled.