Julia: Build is flaky due to ~/.julia/ being used

[wavexx]

I've been following the current master for a long time, however just doing a pull/make often breaks the build. In this case, docs.jl seems to load Logging from ~/.julia/v0.7/, breaking it. Removing Logging from my home makes the build continue, however the build should probably never attempt to use any user module/configuration file.

Output:
````
make

repl/REPL.jl
deprecated.jl
docs/basedocs.jl
markdown/Markdown.jl
docs/Docs.jl

WARNING: deprecated syntax "type" at /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:36.
Use "mutable struct" instead.

WARNING: deprecated syntax "type" at /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:63.
Use "mutable struct" instead.

WARNING: deprecated syntax "parametric method syntax (::Core.Type{Logger}){T <: LogOutput}(name::AbstractString, level::LogLevel, output::Array{T, 1}, parent::Logger) around /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:71".
Use "(::Core.Type{Logger})(name::AbstractString, level::LogLevel, output::Array{T, 1}, parent::Logger) where T <: LogOutput" instead.

WARNING: deprecated syntax "parametric method syntax (::Core.Type{Logger}){T <: LogOutput}(name::AbstractString, level::LogLevel, output::Array{T, 1}) around /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:72".
Use "(::Core.Type{Logger})(name::AbstractString, level::LogLevel, output::Array{T, 1}) where T <: LogOutput" instead.

WARNING: deprecated syntax "parametric method syntax write_log{T <: IO}(output::T, color::Symbol, msg::AbstractString) around /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:85".
Use "write_log(output::T, color::Symbol, msg::AbstractString) where T <: IO" instead.

WARNING: deprecated syntax "parametric method syntax log{T <: IO}(output::T, level::LogLevel, color::Symbol, logger_name::AbstractString, msg...) around /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:97".
Use "log(output::T, level::LogLevel, color::Symbol, logger_name::AbstractString, msg...) where T <: IO" instead.
WARNING: Method definition info(Any...) in module Base at deprecated.jl:3252 overwritten in module Logging at /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:115.
WARNING: Method definition warn(Any...) in module Base at deprecated.jl:3309 overwritten in module Logging at /home/ydelia/.julia/v0.7/Logging/src/Logging.jl:115.
WARNING: could not import Logging.Info into Test
WARNING: could not import Logging.shouldlog into Test
WARNING: could not import Logging.handle_message into Test
WARNING: could not import Logging.min_enabled_level into Test
WARNING: could not import Logging.catch_exceptions into Test
LoadError("sysimg.jl", 506, LoadError("/home/ydelia/downloads/src/julia/usr/share/julia/site/v0.7/Test/src/Test.jl", 1573, LoadError("/home/ydelia/downloads/src/julia/usr/share/julia/site/v0.7/Test/src/logging.jl", 24, UndefVarError(:AbstractLogger))))
* This error is usually fixed by running make clean. If the error persists, try make cleanall.
Makefile:222: recipe for target '/home/ydelia/downloads/src/julia/usr/lib/julia/sys.o' failed
make[1]: [/home/ydelia/downloads/src/julia/usr/lib/julia/sys.o] Error 1
Makefile:101: recipe for target 'julia-sysimg-release' failed
make: * [julia-sysimg-release] Error 2
````

My ~/.juliarc.jl also seems to be used during build, which shouldn't happen.

[c42f]

This is likely because there's a new Logging module in stdlib, but the name clashes with the original Logging.jl which is still registered in the package system.

I'm not quite sure what to do about that, it's unfortunate to be taking the name of an existing package, but I don't see another logical option for stdlib. A workaround would be to blacklist the Logging.jl package from julia 0.7 in METADATA by setting an upper version of 0.6. Again unfortunate, but it looks like this package hasn't been actively developed for a year or two.

[wavexx]

Consider my main point though: the buildn't should use the user's METADATA during build.
Or ~/.juliarc.jl for the matter.

--startup-file should be "no" during build, unless -H/home is already being used.

[KristofferC]

I don't think this should be an issue anymore.