[3rd party plugins] Autoload virtualenv based on project name

jrial commented 7 years ago

It would be nice if this plugin could automatically load the correct virtualenv based on which project was opened. I suggest doing it similar to how https://atom.io/packages/autocomplete-python does it: introducing two variables that can be used in the path name setting.

$PROJECT would be equal to the full path of the project, so that you could use e.g. "$PROJECT/env/"
$PROJECT_NAME would be equal to the name of the folder in which the project resides (which makes it a bit of a misnomer, since my project name and its folder can differ), which can be used in constructions such as "/home/myuser/.virtualenv/$PROJECT_NAME/".

It would be even greater if $HOME were exposed as well, and it would probably be trivial to include with the other two. It's a small thing, but it would allow $HOME/.virtualenv/$PROJECT_NAME instead of /home/myuser/... so that the same Atom installation would be portable across accounts. E.g. if your work account is named differently from your personal account at home, but you prefer the same config on both machines. In fact, I might just open an issue on autocomplete-python for this...

pghilardi commented 7 years ago

@jrial ,

Thanks for the suggestion. The auto-detection of virtual envs would be a a nice feature to this plug-in. I will analyze ways to do this.

pghilardi commented 7 years ago

@jrial ,

What do you think about the following strategy: 1) Inside the folder of the project that you want to work you will open Atom 2) This plug-in will guess the virtualenv associated with this project and activate it to you (looking in the home folder or in the .virtualenvs folder accordingly to your config) 3) The virtualenv will be activated

The idea to expose all these variables may create new bugs if the user does not configure properly. Do you think that the proposed strategy will work for you?

jrial commented 7 years ago

Hey,

Thanks for getting back on this, but that won't mesh with my workflow, and looks rather involved, compared to the minor issue it's supposed to fix.

I jump from project to project during the day. When I open a different project, I do so from within Atom, using Project Manager. Launching from the correct folder in a terminal is no more convenient than simply activating the correct virtualenv and launching from whatever folder the terminal already happens to be in. Your proposal doesn't improve upon the workaround we already have, so I wouldn't put any effort into it.

Perhaps we should look at which bugs would be introduced when the user misconfigures, and see how those can be avoided/mitigated? But as I mentioned, autocomplete-python exposes these variables as well. Seems they resolved the issue by turning it into a prioritised list: the paths are semicolon-separated and take precedence from left to right. If none are found, automatic lookup is used.

See their screenshot:

autocmplete-python settings

pghilardi commented 7 years ago

@jrial ,

Now I think that I understood! I will code/debug/investigate how to introduce these variables as a configuration and I will return to you :)

Thanks for the suggestion again!

pghilardi commented 7 years ago

@jrial ,

Implementing the auto-discovery, I just have one more question. How could I handle when we have multiple projects opened (each project with a virtualenv inside it)?

1) Activate the virtualenv of the last opened project? 2) Ask the user if he wants to activate the virtualenv of the last opened project?

I think that the the strategy number 2 is the best one. What do you think? Because if I activate the virtualenv automatically on project open, maybe this isn't the desired behavior and the user may be confused.

jrial commented 7 years ago

Let's see if I understood you correctly: you have multiple projects open in multiple Atom windows, and all those windows share state and settings so that it's impossible to have each window with its own virtualenv?

pghilardi commented 7 years ago

I have only one Atom instance. I am thinking in a configuration of multiple folders inside the same Atom window, the same Atom instance.

For example: /home/project_1 /home/project_2 /home/project_3

Each project/folder has a virtualenv inside it. Example: /home/project_1/venv When the user click in "Add project folder", I am thinking in suggesting to activate the virtualenv of the project being opened. What do you think?

Are you using the https://github.com/danielbrodin/atom-project-manager package? With the project manager plug-in, the implementation would be different, because you will have one project associated to multiple folders.

jrial commented 7 years ago

Ah, yes, I see. Yes, I use project-manager by danielbrodin, but I have only one folder per project. I guess if there are multiple applications/folders within one project, the venv associated with the first one would make a sensible default.

pghilardi commented 7 years ago

Hi @jrial ,

Until the final solution (integrated with the project-manager project), I have updated the plug-in for the version 0.9.0 and now I am supporting manual input of virtual envs :)

The plug-in searches for envs inside the virtualenvwrapper (usually $HOME/.virtualenvs), inside the $HOME and allows to specify additional virtual envs on settings.

Let me know if this solved part of your problems!

jrial commented 7 years ago

Hey @pghilardi ,

I can load the correct virtualenv manually, but it's not automatically loaded based on project name.

It's up to you if you want to pursue this further, or simply close as a WONTFIX.

pghilardi / atom-python-virtualenv

[3rd party plugins] Autoload virtualenv based on project name #7