Set ENV["PYTHON"] = "" and ENV["R_HOME"] = "*"

[DilumAluthge]

E.g. if you look at the PyCall tests, you'll notice that it uses the system Python, and the tests fail: https://github.com/JuliaCI/NanosoldierReports/blob/master/pkgeval/by_date/2020-08/26/logs/PyCall/1.6.0-DEV-5da96913c2.log

This PR forces Julia to install its own Python and its own R.

cc: @maleadt

[maleadt]

https://github.com/JuliaComputing/NewPkgEval.jl/blob/6b13d769b27c315949e27ba2e0ad778bccadf8c8/runner/Dockerfile#L21 and https://github.com/JuliaComputing/NewPkgEval.jl/blob/6b13d769b27c315949e27ba2e0ad778bccadf8c8/runner/Dockerfile#L33 can then also go?

[DilumAluthge]

Yeah

[maleadt]

Thanks! I've updated the PkgEval bot, please keep an eye on tomorrow's run to see if this broke | fixed anything.

[maleadt]

@DilumAluthge Did you check?

PyCall before: https://github.com/JuliaCI/NanosoldierReports/blob/master/pkgeval/by_date/2020-08/27/logs/PyCall/1.6.0-DEV-5da96913c2.log, finds Python system-wide, errors with UnicodeEncodeError: 'utf-8' codec can't encode characters in position 15-23: surrogates not allowed
PyCall after: https://github.com/JuliaCI/NanosoldierReports/blob/master/pkgeval/by_date/2020-08/28/logs/PyCall/1.6.0-DEV-c9b2cab1a7.log, does something with Conda, but fails with Couldn't find libpython; check your PYTHON environment variable.

[DilumAluthge]

Out of the frying pan, into the fire. RCall (which used to pass before this PR) now fails after this PR.

Let's revert this. Maybe there is a different way to fix PyCall tests.

[maleadt]

Nah, the errors seem like legitimate package issues.

[tkf]

Isn't it better to use a setting that is as default as possible in PkgEval? In Linux, what PkgEval uses now deviates from most of the users' environment for all packages use PyCall. Please note that the failure motivated this PR is also a legitimate package issue that would have been nice to tracked in PyCall issue.

[maleadt]

Please note that the failure motivated this PR is also a legitimate package issue that would have been nice to tracked in PyCall issue.

Sure, that was why I posted https://discourse.julialang.org/t/ann-nanosoldier-package-evaluation-with-badges/33339 back when :-) I don't have the time to wade through all package failures and find the most appropriate fix. If you think that providing python as part of the PkgEval environment better aligns with common user set-ups, then please propose a change. I figured that, with much of the Julia ecosystem moving towards providing their own binaries (using artifacts) this would be the way to go for PyCall too.

[tkf]

I apologize if the tone of my previous comment had the impression of blaming you or anyone. I just wanted to point out that it's often a good idea to propagate the root cause to the upstream.

the Julia ecosystem moving towards providing their own binaries

I do understand the frustration of the fragility with external libraries some users experience. However, no all Julia users are non-Python users. As a member of technical computing community as a whole and not just a ecosystem within Julia, I do hope Julia-Python bridge is as open as possible. Of course, agenda of PkgEval probably is to improve the user experience within Julia ecosystem and it's maybe the best direction given the limited resource.

Anyway, besides the "philosophical" standpoint, I don't think it's relevant to my main point that it's ideal to change the default in upstream (=PyCall). This probably needs to wait until PyCall 2.0, though (I just noted this in 2.0 roadmap JuliaPy/PyCall.jl#629 (comment)).