Additional variable for paths needed
Alexx-G opened this issue · 18 comments
Settings for python executable and additional packages are very useful, but they don't cover the use case when you've a separated folder for virtualenvs.
E.g. I manage virtualenvs with virtualenvwrapper and all my virtualenvs are stored in ~/.virtualenvs/.
So in this case I just can't use $PROJECT variable.
Launching of atom from activated virtualenv doesn't work for me because usually I have more than 1 running instances of atom. So, if I've opened first instance of atom from venv1, the second instance started from venv2 will handle packages from venv1.
It'll be handy to have a $PROJECT-ROOT variable which holds only root dirname, in that case I could configure paths like ~/.virtualenvs/$PROJECT-ROOT/.
Is it possible to add this option?
Could you not add your virtualenv dir to your Atom project thus making it possible to use $PROJECT?
As I said, I use virtualenvwrapper for easier management of multiple virtualenvs which keeps virtualenvs in a single place.
However, I've created a symlink from project folder to the virtualenv and it works. But this means that I have to do the same for each project.
In Atom, single project may have multiple root paths.
Can you try to run your atom like atom path/to/your/project ~/.virtualenvs/my-project-virtual-env? You should see two root folders in your Tree View.
Or just add another project folder and restart:
It should work.
Yeah, it basically works.
But won't this solution slow down indexing of the project?
I think that's the best we can get right now short of adding UI for per-project interpreter selection.
It shouldn't slow down especially if you configure your atom to ignore
everything inside.
On Mon, Dec 14, 2015, 21:19 Patryk Zawadzki notifications@github.com
wrote:
I think that's the best we can get right now short of adding UI for
per-project interpreter selection.—
Reply to this email directly or view it on GitHub
#143 (comment)
.
So, options are:
- Create symlink to venv
- Add virtualenv folder as project root.
Both options doesn't need additional configuration in package settings.
And using something like atom-project-manager makes the second option acceptable.
So, basically, this solves my problem. It needs adjustments for each project, but I don't think that it's a big deal.
Thanks.
@sadovnychyi As you pointed, after adding venv specific folders as ignored to Atom settings, it doesn't index them.
@sadovnychyi Nice! Thanks for update!
I've configured already all of my project, but good to know about new option.
I like that you can add the virtualenv path to the project's path in projects.cson.
However, this makes the virtualenv folder appear in the tree view which is a "collateral damage".
Wouldn't it be simple to add a virtualenv: /path/to/virtualenv key-value pair to the projects.cson which would only be read by the autocomplete-python package. I believe that would solve this issue once and for all. The projects.cson file is here to set project specific variable that may or may not be used by packages.
Additionnaly, a command to automate the process would be nice. Something like : "Autocomplete Python: Set virtualenv"
@obust there's no projects in Atom core (yet), and since you can pretty much use any virtual environments with $PROJECT and $PROJECT_NAME substitutions I'm not seeing an issue here. But I'm always open to pull requests if you think something could be improved!
Oh my bad, i see project-specific settings is still an open issue #5168
I was led to believe otherwise since both project-manager and project-plus make use of the same ~/.atom/projects.cson file.
Also, when you "Add a project folder" (which is an Atom command) it adds the path to this file as well. I tested this while disabling project-manager. It seems that atom does consider this file as a standard for project-specific variables.
So i am confused here.
It didn't work for me with latest beta. Added new folder into a project -- cannot see projects.cson in any of folders created.
Could you explain your use case for this and while using substitutions is not enough for you?
$PROJECT/venv/bin/python3;$PROJECT/venv/bin/python;~/venvs/$PROJECT_NAME/bin/python3 – this would try to use python3 inside of your project's virtual environment if possible, but if it does not exists -- falling back on the next one and trying python, then checking your home folder. With such priorities I believe you could configure all of your projects.
Check your /home/<username>/.atom/projects.cson
The substitution works well for most cases, it just happen that i use virtualenvwrapper and sometimes my virtualenv names don't match my project name (i could explain why but that's not relevant here). So having an arbitrary option to clearly tell where the virtualenv is rather than making assumptions would be a more robust solution.
~/.atom·ls /Users/sadovnychyi/.atom
total 64 19:18:30
drwxr-xr-x 15 sadovnychyi staff 510B Jun 24 19:05 ./
drwxr-xr-x+ 119 sadovnychyi staff 4.0K Oct 6 00:46 ../
-rw-r--r--@ 1 sadovnychyi staff 10K Aug 16 18:15 .DS_Store
drwxr-xr-x 798 sadovnychyi staff 26K Oct 5 23:17 .apm/
drwxr-xr-x 5 sadovnychyi staff 170B Jul 9 03:57 .node-gyp/
drwxr-xr-x 5 sadovnychyi staff 170B Oct 5 19:05 blob-store/
drwxr-xr-x 32 sadovnychyi staff 1.1K Aug 5 17:45 compile-cache/
lrwxr-xr-x 1 sadovnychyi staff 45B Aug 26 2015 config.cson@ -> /Users/sadovnychyi/dotfiles/.atom/config.cson
lrwxr-xr-x 1 sadovnychyi staff 45B Aug 26 2015 init.coffee@ -> /Users/sadovnychyi/dotfiles/.atom/init.coffee
lrwxr-xr-x 1 sadovnychyi staff 45B Aug 26 2015 keymap.cson@ -> /Users/sadovnychyi/dotfiles/.atom/keymap.cson
drwxr-xr-x 45 sadovnychyi staff 1.5K Oct 6 18:12 packages/
drwxr-xr-x 2 sadovnychyi staff 68B Oct 7 00:24 recovery/
lrwxr-xr-x 1 sadovnychyi staff 47B Aug 26 2015 snippets.cson@ -> /Users/sadovnychyi/dotfiles/.atom/snippets.cson
drwxr-xr-x 55 sadovnychyi staff 1.8K Feb 17 2016 storage/
lrwxr-xr-x 1 sadovnychyi staff 45B Aug 26 2015 styles.less@ -> /Users/sadovnychyi/dotfiles/.atom/styles.less
Still nothing.
I understand, but there's no official format for that file, so I'm not sure how to act.
Ok, nevermind then, maybe later ;)
@sadovnychyi a very frequent case to have naming differences is for example when testing on a single branch a separate virtualenv when upgrading requirements and frameworks, while you want to keep your original virtualenv to work on master or other branches...
I am very interested by this feature, very well supported by PyCharm for example, but indeed blocked by the Atom core :-/