title: Detaching and re-attaching "tools:rstudio"
body: <p>a.k.a playing with fire...</p>
  
  <p>The following does not work:</p>
  
  <pre><code>rstd.obj &lt;- as.environment("tools:rstudio")
  detach("tools:rstudio")
  attach(rstd.obj, name="tools:rstudio")
  </code></pre>
  
  <p>Well, it seems to work, but then all sorts of weird errors start popping up.  The problem is that very annoyingly (though I'm sure for a very good reason) <code>attach</code> makes a copy of the environment and attaches that, instead of attaching the environment directly:</p>
  
  <pre><code>rstd.obj
  # &lt;environment: 0x000000000930edd0&gt;
  # attr(,"name")
  # [1] "tools:rstudio"
  as.environment("tools:rstudio")
  # &lt;environment: 0x000000000a21b4c8&gt;
  # attr(,"name")
  # [1] "tools:rstudio"
  </code></pre>
  
  <p>Notice how the environments are actually different (this is also confirmed if you look at the source code for <code>do_attach</code> in <code>src/main/envir.c@2124(R3.0.2)</code> where the copy is made).</p>
  
  <p>This, however, works totally fine (after restarting RStudio to reset everything):</p>
  
  <pre><code>rstd.obj &lt;- as.environment("tools:rstudio")
  rstd.parent &lt;- as.environment("package:stats")  # this was #3 on search path for me
  detach("tools:rstudio")
  
  # WARNING: YOU'RE PLAYING WITH FIRE IF YOU RUN THIS, DO
  # SO AT YOUR OWN RISK:
  
  parent.env(.GlobalEnv) &lt;- rstd.obj
  parent.env(rstd.obj) &lt;- rstd.parent
  </code></pre>
  
  <p>Instead of using <code>detach</code>/<code>attach</code>, we just <code>detach</code>, and forcibly insert the object back into the search path using <code>parent.env&lt;-</code>.  On the flipside, I'm guessing doing the above is probably close to what R Core had in mind when they warned in <code>?parent.env</code>:</p>
  
  <blockquote>
    <p>The replacement function <code>parent.env&lt;-</code> is extremely dangerous as it can be used to destructively change environments in ways that violate assumptions made by the internal C code. It may be removed in the near future. </p>
  </blockquote>
  
  <p>Another alternative to get around this problem is to use <code>detach</code>/<code>attach</code>, but then cycle through all the functions in the <code>tools:rstudio</code> environment on the search path and reset their environments to the copy of the original environment now on the search path (incidentally, this is why Rstudio starts breaking: the function environments are still the object removed from the search path, but that environment is not in the search path anymore, only a copy of it).  This feels incredibly hacky though.</p>
  
  <p>Also, if anyone knows more details about what the "assumptions made by the internal C code" are I'd be very interested to hear them.  Obviously, we could introduce circularities in the search path (no, I didn't accidentally just do that messing around with these examples...), but are there other problems as well?</p>
  
  <p>EDIT: regarding the above, super useful tidbit from <strong><a href="http://r.789695.n4.nabble.com/Making-parent-env-lt-an-error-for-package-namespaces-and-package-imports-td4698432.html" rel="nofollow">R-devel</a></strong>:</p>
  
  <blockquote>
    <p>I'd like to propose a change to the R language so that calling
    'parent.env&lt;-' on a package namespace or package imports is a runtime
    error. 
    ...
    I'd also like to make calling parent.env&lt;- on an environment on the
    call stack an error, for the same reasons, but it's not so obvious to
    me how to implement that efficiently right now.  Could we at least
    document that as being 'undefined behaviour'? </p>
  </blockquote>
  
  <p>And Luke Tierney's answer:</p>
  
  <blockquote>
    <p>I'll look into it </p>
  </blockquote>
  
  <p>This seems to confirm the concern is changing the call stack in call or search path in a way R may not track, as opposed to generally thinking <code>parent.env&lt;-</code> is dangerous for other environment chains (clearly reading b/w lines here).</p>