I’ve tried the the new Keras .devcontainer
I think using that locally with remote containers is not so much usable with a Keras local checkout as you are going to create by default all the build files and new file with the root user/permission but on the host directory. So when you are back on your host you will find many root files and folders.
This is why we have already discussed with the SIG-build to add “a standard” UID/GUID in the Docker image:

  

      github.com/tensorflow/build
  

  
    
  
    
  

  
    
      (Experimental) Single Multi-Stage Dockerfile
    

    
      tensorflow:master ← tensorflow:dockerfiles
    

    
      
        opened 
        
          
        
        Jan 27, 2021
      
      

      
        
          
          angerson
        
      

      
        
          +1002
          -0
        
      
    
  


  
    Here's my progress on a multi-stage Dockerfile (see https://github.com/tensorflo…w/tensorflow/issues/46062).

I based it on a mixture of Sean's suggested layout, the current official dockerfiles, and the current unofficial RBE dockerfiles. Since I made progress, I thought I'd put it into a PR so I can get some early feedback on the general ideas. Some points and questions:

1. I built and tested these with build.sh.
1. Most notably, the `devel` target can't build TF, and I'm not sure why. It fails pretty late at a weird spot.
1. The idea for backwards compatibility would be: every time TF cuts a branch, the `master` directory gets cloned into a folder with the same name as the new branch, and any direct references would be updated (git clone, etc.).
1. These need some kind of verification test suite.
1. I didn't bother trying to recreate the manual package install in the runtime container.
1. I still don't know how the shims really work, and some things from cleanup_cuda_install.sh are only there because they've always been in our images, but I don't know why.
1. Are all these pyenv installations actually useful?
1. DevInfra would need another layer with more tools for our own CI, but presumably we'd want to keep the official blessed build environment image pretty slim.
1. Setting up pyenv correctly looks like it could be tricky and will be different in runtime and devel.
1. Ideally we'd provide an official suite of bazelrc files to go alongside this for the devel containers.
     - Then we could also maybe offer access to a RO cache the same as our real builds use, eventually

You can check it out yourself if you clone this PR and run the commands in build.sh yourself.

@seanpmorgan @perfinion @yongtang @bhack
  

  

  
    
    
  

  


I think also that requirements.txt is quite heavy and so it lags on the Codespace/Container bootstrap as it requires to install tf-nightly (so the GPU wheel) and its dependencies on every new Codspace/Docker container instance that you launch.
Codespaces also are CPU only VMs so you have also the useless overhead of a GPU image + GPU wheel downloads before you can start to code something.
Isn’t better to rely on Keras nightly docker images, CPU only for Codespaces or for local CPU only machines, where these dependencies are already installed?
Just a side note, I don’t know if anyone here could get in contact with the Bazel team.
We are suffering a little bit of usability in Codespace/Vsocde for the missing test integration in the Google official VsCode Bazel extension:

  

      github.com/bazelbuild/vscode-bazel
  

  
    
  
	  
  

  
    
      [Feature request] Integrate with Test Explorer
    

    
      
        opened 
        
          
        
        Feb 20, 2020
      
      


      
        
          
          nicolasnoble
        
      
    

    
    
  


  
    There is a [Test Explorer UI extension](https://marketplace.visualstudio.com/ite…ms?itemName=hbenl.vscode-test-explorer) available, which itself provides a [Test Adapter API to discover and run tests](https://github.com/hbenl/vscode-example-test-adapter). An example of such test adapter is the [Catch2 and GoogleTest adapter](https://marketplace.visualstudio.com/items?itemName=matepek.vscode-catch2-test-adapter).

It would be very neat if the vscode-bazel extension was integrating with either Test Explorer directly, or with the GoogleTest adapter, in order to provide the list of tests, and the ability to spawn a [Visual Studio Code Debugger instance](https://code.visualstudio.com/docs/cpp/cpp-debug) through the Test Explorer UI.