<p dir="auto">I have RHEL 7 distribution behind a proxy. I installed julia using official documentation and everything seemed to be fine.</p>
<p dir="auto">Here's the yum listing (note, libgit2 is 0.23.1)</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="Installed:
  julia.x86_64 0:0.5.0-1.el7.centos

Dependency Installed:
  arpack.x86_64 0:3.1.3-2.el7
  atlas.x86_64 0:3.10.1-7.el7
  dSFMT.x86_64 0:2.2.3-4.el7.centos
  fftw-libs-double.x86_64 0:3.3.3-8.el7
  http-parser.x86_64 0:2.7.1-3.el7
  julia-common.noarch 0:0.5.0-1.el7.centos
  julia-devel.x86_64 0:0.5.0-1.el7.centos
  libgit2.x86_64 0:0.23.3-1.el7.centos
  llvm3.7-libs.x86_64 0:3.7.1-3.el7.centos
  openblas-threads.x86_64 0:0.2.19-4.el7
  openlibm.x86_64 0:0.5.3-1.el7
  openspecfun.x86_64 0:0.5.3-1.el7
  pcre2.x86_64 0:10.21-11.el7
  suitesparse.x86_64 0:4.4.5-2.el7.centos
  tbb.x86_64 0:4.1-5.20130314.el7
  utf8proc.x86_64 0:2.0.2-1.el7.centos

Complete!"><pre class="notranslate"><code class="notranslate">Installed:
  julia.x86_64 0:0.5.0-1.el7.centos

Dependency Installed:
  arpack.x86_64 0:3.1.3-2.el7
  atlas.x86_64 0:3.10.1-7.el7
  dSFMT.x86_64 0:2.2.3-4.el7.centos
  fftw-libs-double.x86_64 0:3.3.3-8.el7
  http-parser.x86_64 0:2.7.1-3.el7
  julia-common.noarch 0:0.5.0-1.el7.centos
  julia-devel.x86_64 0:0.5.0-1.el7.centos
  libgit2.x86_64 0:0.23.3-1.el7.centos
  llvm3.7-libs.x86_64 0:3.7.1-3.el7.centos
  openblas-threads.x86_64 0:0.2.19-4.el7
  openlibm.x86_64 0:0.5.3-1.el7
  openspecfun.x86_64 0:0.5.3-1.el7
  pcre2.x86_64 0:10.21-11.el7
  suitesparse.x86_64 0:4.4.5-2.el7.centos
  tbb.x86_64 0:4.1-5.20130314.el7
  utf8proc.x86_64 0:2.0.2-1.el7.centos

Complete!
</code></pre></div>
<p dir="auto">However, the further Pkg.add("IJulia") invocation failed on METADATA.jl cloning.</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="julia&gt; Pkg.add(&quot;IJulia&quot;)
INFO: Initializing package repository /root/.julia/v0.5
INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
ERROR: GitError(Code:ERROR, Class:Net, No Content-Type header in response)
 in #clone#109(::String, ::Bool, ::Ptr{Void}, ::Nullable{Base.LibGit2.AbstractCr                                              edentials}, ::Function, ::String, ::String) at ./libgit2/libgit2.jl:327
 in add(::String) at ./pkg/pkg.jl:100
 in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64
 in macro expansion at ./REPL.jl:95 [inlined]
 in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68"><pre class="notranslate"><code class="notranslate">julia&gt; Pkg.add("IJulia")
INFO: Initializing package repository /root/.julia/v0.5
INFO: Cloning METADATA from https://github.com/JuliaLang/METADATA.jl
ERROR: GitError(Code:ERROR, Class:Net, No Content-Type header in response)
 in #clone#109(::String, ::Bool, ::Ptr{Void}, ::Nullable{Base.LibGit2.AbstractCr                                              edentials}, ::Function, ::String, ::String) at ./libgit2/libgit2.jl:327
 in add(::String) at ./pkg/pkg.jl:100
 in eval_user_input(::Any, ::Base.REPL.REPLBackend) at ./REPL.jl:64
 in macro expansion at ./REPL.jl:95 [inlined]
 in (::Base.REPL.##3#4{Base.REPL.REPLBackend})() at ./event.jl:68
</code></pre></div>
<p dir="auto">I decided to post it as a bug, because</p>
<ol dir="auto">
<li>Proxy settings seems to work fine. Without environment variables HTTP_PROXY/HTTPS_PROXY being set I'm getting the error <code class="notranslate">Failed to connect</code>, not the one posted above.</li>
<li>Git is also configured fine. And actually, I overrulled Pkg.init() by manually running this code with <code class="notranslate">run()</code>: <code class="notranslate">git clone [github]/METADATA.jl [HOME]/.julia/v.0.5/METADATA</code>.</li>
<li>I haven't find similiar errors in already posted issues.</li>
</ol>
<p dir="auto">I think it might be a good idea if we revised the NamedTuple internals to be something like this:</p>
<p dir="auto"><code class="notranslate">(; a = 1, b = 2)</code> goes to <code class="notranslate">(name"a" =&gt; 1, name"b" =&gt; 2)</code>, where the name string macro would pull the symbol into the type domain. I can see the following advantages</p>
<ul dir="auto">
<li>It would allow mixing unnamed and named entries in the same tuple</li>
<li>It would allow for much easier programmatic construction of named tuples</li>
<li>It would unify the tuple and the NamedTuple internals</li>
<li>It would remove the need for generated functions in the NamedTuple code (these kind of types are much easier to handle with recursion)</li>
</ul>
<p dir="auto">I can see the following disadvantages:</p>
<ul dir="auto">
<li>NamedTuple construction automatically checks for duplicate keys, but this syntax would allow duplicate keys, perhaps only throwing an error when <code class="notranslate">getproperty</code> is called (although just returning the first match could also be a valid option)</li>
</ul>