PyCall hardcodes paths in ~/.julia so copying packages to another workstation with different username fails

The Julia manual says

For machines with no Internet connection, packages may be installed by copying the package root directory… from a machine with the same operating system and environment.

I interpreted “environment” here to mean things like GCC version, etc., but not, e.g., username.

If I install PyCall (tested on ancient CentOS 6.5, with Julia 0.5.1) for a user named fasih and then copy the resulting ~/.julia/v0.5 package to another computer where my username is fasiha (an extra a at the end), PyCall doesn’t work because the old username has been hardcoded:

[fasiha@localhost bin]$ ./julia
               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.1 (2017-03-05 13:25 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org/ release
|__/                   |  x86_64-pc-linux-gnu

julia> using PyCall
ERROR: InitError: error compiling __init__: could not load library "/home/fasih/.julia/v0.5/Conda/deps/usr/lib/libpython2.7"
/home/fasih/.julia/v0.5/Conda/deps/usr/lib/libpython2.7.so: cannot open shared object file: Permission denied
 in _include_from_serialized(::String) at ./loading.jl:150
 in _require_from_serialized(::Int64, ::Symbol, ::String, ::Bool) at ./loading.jl:187
 in _require_search_from_serialized(::Int64, ::Symbol, ::String, ::Bool) at ./loading.jl:217
 in require(::Symbol) at ./loading.jl:371
during initialization of module PyCall

Note the error messages references fasih (the original username).

Ideally, PyCall and relatives can be copied from a networked computer to a computer without network access, as promised by the manual, without having to synchronize usernames.

If I try a brute-force search-and-replace, viz., in ~/.julia/v0.5/PyCall, running $ find -type f -print0 | xargs -0 sed -i 's/fasih/fasiha/g', on one system using PyCall segfaulted, though on my test virtual machine, this seems to work.

So, as far as the goal of installing PyCall (and PyPlot) on a non-networked computer, is a search-and-replace the recommended way to work around this problem, or is it possible for PyCall to avoid hardcoding paths?

Thank you!

Commencez par reproduire using PyCall après avoir copié ~/.julia/v0.5 sur une machine avec un nom d’utilisateur différent, en utilisant les chemins signalés sous PyCall et Conda/deps comme points de départ. C’est terminé lorsque PyCall et les paquets associés se chargent sur la machine hors ligne sans recherche-remplacement spécifique au nom d’utilisateur.