install into a single global directory, not in deps

[yeonsookimdev]

From https://github.com/JuliaPy/Conda.jl/issues/123:

Currently we install into the deps directory. However, in Julia 1.0, packages are no longer updated in place, this means that every time you update Conda.jl it needs to re-install anaconda, which is wasteful and breaks things like PyCall that expect libpython to stay in one place.

From https://github.com/JuliaPy/Conda.jl/pull/126:

Drops Julia 0.6 since in Julia 0.6 there is already a single global directory (~/.julia/v0.6/Conda/deps/usr) and I don't think we want to move it.

I think WinRPM has this re-installation in deps directory issue, too.

[davidanthoff]

I think we are getting one copy of all binaries per installed WinRPM version, right? Given that WinRPM is not seeing much love these days, maybe that is ok? I would be surprised if we were to see many releases in this repo here, which makes me think that the issue is less urgent here.

[yeonsookimdev]

we are getting one copy of all binaries per installed WinRPM version

The problem comes when we execute Pkg.gc(), then all previous version will be gone. Then, some packages which use hardcoded WinRPM path, by intension or precompiled result, must be built again manually.

the issue is less urgent here.

You're right. This issue is not urgent one. I just wanted to share there could be a problem when we keep installing in deps directory in v0.7/v1.0.

[davidanthoff]

Then, some packages which use hardcoded WinRPM path, by intension or precompiled result, must be built again manually.

Ah, I hadn't thought about that scenario. Is there a way to change those packages to only ever use binaries from the deps folder of WinRPM.jl that is the one the package manager deems the right one for them?

[yeonsookimdev]

Reading WinRPM.installdir at the begining of top-level module can be one solution. Using binary manager packages like BinaryProvider.jl or BinDeps.jl could be another solution. (I didn't test this with precompiled code yet, but it would work fine.)

LibFoo.jl, an example project of BinaryProvider, writes the path into deps/deps.jl file calling write_deps_file, which would not be avaialbe after we update and gc previous packages. https://github.com/JuliaPackaging/BinaryProvider.jl/blob/master/test/LibFoo.jl/src/LibFoo.jl#L7

Of course, we can rebuild packages when they complain about things, then it would download all binaries through WinRPM again and rewrite deps/deps.jl.

Another possible case is when people don't gc things. Then, after install some binaries, deps.jl still points to previous directory, which could make us confused. Of course this also can be resolve by gc and rebuild them.

So this is not critical, if anything goes wrong, we just build things again. I wonder this can be detected by package manager and trigger rebuild before people encounter it. (Or, maybe provide ~/.julia/deps/ directory and allow packages to use their own deps directory under there like ~/.julia/deps/Conda/ or ~/.julia/deps/WinRPM/.)