Document usage of $PATH for {configuration, virtualenv package}-less virtualenv/flake8 settings

[ronjouch]

Hi, this is not really an "issue", more of a discussion of a nice hack I use that might deserve documentation. If you are interested, feedback welcome, and I can make a PR adding a paragraph at the end of README.md.

---

I love this package, but don't like very much having to go to Settings to set my python / $PATH each time I work on a Python 2 project.

→ Since I start Atom from the command-line anyway (atom /path/to/project_folder/, for which Atom will remember open files), rather than having to murk with Atom configuration, I set up:

• The usual virtualenv with my python2/python3/pypy choice for project A/B/C.
• A folder with a flake8 symlink pointing to my non-default flake8 (in my case under Arch Linux, ln -s /usr/bin/flake8-python2 ~/.flake8-python2/flake8)

Then I can start an Atom session...

• ... for a python3 / stdlib-only project with atom /path/to/vanilla_project/
• ... for exotic projects by prepending a modification to $PATH. For example, I start an Atom session for my python2-based dailygrooves with PATH=~/.virtualenvs/dailygrooves/bin:~/.flake8-python2/:$PATH atom ~/projects/dailygrooves/

Repeatable, stateless virtualenv/flake8 Atom environments! 🎉 . Thoughts? I started the same discussion at AtomLinter/linter-flake8#71

[sadovnychyi]

Make a PR for sure if you think that it will be useful for somebody.
I didn't really understand how it works though. Isn't JEDI/flake8 works for both python3 and python2 files by default without switching between them?

[ronjouch]

@sadovnychyi thanks for the fast feedback. Answering your questions:

Make a PR for sure if you think that it will be useful for somebody.

Okay, waiting for feedback from AtomLinter too, then will make a PR.

I didn't really understand how it works though.

I'll do my best to be crystal clear in the PR. The gist of it is that, by prepending the $PATH environment variable with paths containing the python and flake8 we want (or links to them), we "force" Atom to use them rather than the default ones living a path later in $PATH

Doesn't JEDI/flake8 work for both python3 and python2 files by default without switching between them?

No:

• JEDI seems to be smart on its py2/py3 detection, but it will still suffer from not using the the python from your virtualenv if you use third-party (non-stdlib) packages. When using the virtualenv python, jedi is able to parse 3rd-party site-packages and gives you awesome dot completion on modules and docstrings for third-party libraries.
• Flake8 is dumb and will assume you use the good binary (in Arch Linux, flake8 for py3 and flake8-python2 for py2). For example, if I open a py2 project with a default Atom on Arch (where flake8, for py3, is the default), Flake8 will expect print() function calls, and the print statements will result in errors E901 - SyntaxError: invalid syntax.

Ping @steelbrain (from upstream Linter): sorry to bother you, I'm thinking this discussion might be of interest to you. Are my suggestions reasonable or am I a crackhead? If the former, is this the right place to talk about the technique? On the flake8 side, would the Linter api let us do something smarter / more automatic?

[steelbrain]

@ronjouch I've been awake for almost two days now so my mind isn't completely functioning. but the functioning part of it says that if you want to select executables based on your project, You could modify your process.env.PATH instead of defining a special case in each package, I mean have something like this in your init file

var realPath = process.env.PATH
var Path = require('path')
atom.project.onDidChangePaths ->
  process.env.PATH = realPath + Path.delimiter + atom.project.getPaths().map(function(entry){
  return entry + Path.sep + '.env'
}).join(Path.delimiter)

and then make the packages use non-absolute executable paths, for example python3 instead of /usr/local/bin/python3.

[ronjouch]

You could modify your process.env.PATH instead of defining a special case in each package

@steelbrain That would work (nit: if instead of assuming a virtualenv per project living in /path/to/project/.env we'd look for a virtualenv in ~/.virtualenvs/<atomProjectFoldername>).

@sadovnychyi but all things considered, I'm proposing a solution to a non-existent problem because launching from an activated virtualenv will do the same path manipulation and is the pythonic way to do. Forget about the manual $PATH modification, I filed #57 suggesting proper virtualenv activation.