Updating installation guide

[jlperla]

Makes the importance of ENV["PYTHON"] clear, and points out that you need to relate the python interpreter and the julia executale

[stevengj]

I thought there was support for using a different PyCall configuration in Julia vs pyjulia; am I misremembering?

[jlperla]

Might be... All I know is this was the source of all of my problems with the library

[stevengj]

Supporting a pyjulia-specific PyCall configuration is a key feature — otherwise, it will be impossible to install pyjulia into more than one Python environment on the same machine.

[stevengj]

See also https://github.com/JuliaPy/pyjulia/blob/master/julia/fake-julia/README

[stevengj]

@Keno, has something bitrotted here?

[jlperla]

Supporting a pyjulia-specific PyCall configuration is a key feature — otherwise, it will be impossible to install pyjulia into more than one Python environment on the same machine.

Yup, a major issue, especially with virtualenv, etc. If there is some hidden steps that a relatively non-technical user can try to work through, I can ask an RA to help either document or debug?

[tkf]

support for using a different PyCall configuration in Julia vs pyjulia

I just noticed Travis CI with CROSS_VERSION=1 is put in allow_failures (since #149?): https://travis-ci.org/JuliaPy/pyjulia/builds/394733702 I suppose it's not working for a while.

But it looks like it's working on Windows: https://ci.appveyor.com/project/Keno/pyjulia/build/1.0.90

A bit tangential but I wonder if Pkg3 can help pyjulia/PyCall. There is a discussion on supporting 32 and 64 bit binaries by separating precompilation paths. JuliaLang/Pkg.jl#93 Would it be possible to get rid of fake-julia using the same mechanism? I'm thinking something like Pkg3-tracked environment per Python's virtualenv.

[tkf]

This should already be fixed in master. Please open a new issue/PR if there is something to be improved.