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

The Julia manual [says](http://docs.julialang.org/en/stable/manual/packages/#offline-installation-of-packages)

> 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](http://docs.julialang.org/en/stable/manual/packages/#offline-installation-of-packages), 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!

Start by reproducing `using PyCall` after copying `~/.julia/v0.5` to a machine with a different username, using the reported paths under `PyCall` and `Conda/deps` as the starting points. Done means PyCall and related packages load on the offline machine without username-specific search-and-replace.

索引モデルが issue の本文から書いたものです。