microsoft / vscode-remote-try-rust Goto Github PK

Rust sample project for trying out Dev Containers

Home Page: https://aka.ms/vscode-remote/containers/getting-started

License: MIT License

Rust 100.00%

vscode-remote-try-rust's Introduction

Try Out Development Containers: Rust

A development container is a running container with a well-defined tool/runtime stack and its prerequisites. You can try out development containers with GitHub Codespaces or Visual Studio Code Dev Containers.

This is a sample project that lets you try out either option in a few easy steps. We have a variety of other vscode-remote-try-* sample projects, too.

Note: If you already have a Codespace or dev container, you can jump to the Things to try section.

Setting up the development container

GitHub Codespaces

Follow these steps to open this sample in a Codespace:

Click the Code drop-down menu and select the Open with Codespaces option.
Select + New codespace at the bottom on the pane.

For more info, check out the GitHub documentation.

VS Code Dev Containers

If you already have VS Code and Docker installed, you can click the badge above or here to get started. Clicking these links will cause VS Code to automatically install the Dev Containers extension if needed, clone the source code into a container volume, and spin up a dev container for use.

Follow these steps to open this sample in a container using the VS Code Dev Containers extension:

If this is your first time using a development container, please ensure your system meets the pre-reqs (i.e. have Docker installed) in the getting started steps.
To use this repository, you can either open the repository in an isolated Docker volume:
- Press F1 and select the Dev Containers: Try a Sample... command.
- Choose the "Rust" sample, wait for the container to start, and try things out!
  
  Note: Under the hood, this will use the Dev Containers: Clone Repository in Container Volume... command to clone the source code in a Docker volume instead of the local filesystem. Volumes are the preferred mechanism for persisting container data.
Or open a locally cloned copy of the code:
- Clone this repository to your local filesystem.
- Press F1 and select the Dev Containers: Open Folder in Container... command.
- Select the cloned copy of this folder, wait for the container to start, and try things out!

Things to try

Once you have this sample opened, you'll be able to work with it like you would locally.

Some things to try:

Edit:
- Open main.rs
- Try adding some code and check out the language features.
- Make a spelling mistake and notice it is detected. The Code Spell Checker extension was automatically installed because it is referenced in .devcontainer/devcontainer.json.
- Also notice that utilities like rls and the Rust Analyzer extension are installed. Tools are installed in the mcr.microsoft.com/devcontainers/rust image and Dev Container settings and metadata are automatically picked up from image labels.
Terminal: Press ctrl+shift+` and type uname and other Linux commands from the terminal window.
Build, Run, and Debug:
- Open main.rs
- Add a breakpoint (e.g. on line 8).
- Press F5 to launch the app in the container.
- Once the breakpoint is hit, try hovering over variables, examining locals, and more.
Install the GitHub CLI using a Dev Container Feature:
- Press F1 and select the Dev Containers: Configure Container Features... or Codespaces: Configure Container Features... command.
- Type "github" in the text box at the top.
- Check the check box next to "GitHub CLI" (published by devcontainers)
- Click OK
- Press F1 and select the Dev Containers: Rebuild Container or Codespaces: Rebuild Container command so the modifications are picked up.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com.

When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

License

Copyright © Microsoft Corporation All rights reserved.
Licensed under the MIT License. See LICENSE in the project root for license information.

vscode-remote-try-rust's People

Contributors

Stargazers

Watchers

Forkers

markzuber vdedyukhin dipson xuhongxu96 johanneslueke pratikpc zwobill hemantkashniyal valery-shinkevich sheyne bhaskers-blu-org2 morlassino taffywrinkle drewwyatt claudiusgonzo tatsuya6502 eschryn chaoyun8888 gilescope rachelguo76 vso-dev2 joannawu-wd codespaces-test-01 codespaces-test-02 rodrmoya codespaces-test-08 bamurtaugh azusa global-localhost global19 global19-atlassian-net qwert666 ryuheechul leogomes lorenpaulsen oodachi hoisjp newgyu tangshimei qpc-database kobimorad technicalconsultant321 wasmup skalarfeilds79 ryomasao totechite richardglenski sanbieber roccqqck reactivethings codemoudi thelmuxkriovar edwardt nyctef thomasmatecki jamb0bobo cruise-group 20kpk henrikbach1 bhargavborse lukaszmn-forks gazimbeisaac tiago-peres ddanggle mrgcyrus35 tritriper stephenchege mdmundo chrmarti lynsei waltritscher felipecrs ibx-edu ptzagk test-mass-forker-org-1 uramnoil cyndi5 01091081878 elmurci elanhasson therapon buo keijitokunaga kotokaze isabella232 amir-arad mmusnjak zarakikanzaki olguzzar oblonka reubenmiller mi-zy pvcarrera aagbodo jemytojedno brunoscience chinomacnleandoe zarthzurth hashd2035 raytangrt

vscode-remote-try-rust's Issues

Update for monorepo?

Can this repo and specifically the debugging with VSCode be updated to handle a monorepo where there are several crates?

I would like the debug configuration to be able to work regardless of where in the monorepo the project is.

>stop<

stop

Originally posted by @sanbieber in #7 (comment)

open container and press F5 error in win10

Cargo invocation has failed: Error: could not launch cargo: Error: spawn cargo ENOENT

New Terminal windows default to the root user

When creating a new Terminal window in VS Code by pressing Ctrl+Shift+` , the default user for the terminal is root because of how the Dockerfile is building the container. This can lead to the chance of accidentally creating files in the container as root instead of the vscode user (which maps back to the local user).

Would it make sense to include the following USER statement to the end of the .devcontainer/Dockerfile:

USER $USERNAME

This way any new Terminal window that is created by VS Code automatically drops into the vscode user. Anything created in the Terminal windows would then have the correct permissions outside of the container.

Thoughts? Good/Bad?

If the answer is Good, maybe we should also replicate this across the Dockerfile in all of the vscode-remote-try-<language> repos as well.

Debug Value Formatting

I'm unsure if others have had this problem, but my debugger was not showing values in a very human-readable format after starting this up. Please see the provided screenshots of what I was seeing both before and after my fix.

Assuming I didn't just configure something incorrectly on my part before this step, I'd suggest the following be added to the RUN command of the Dockerfile in this repo to fix it:

    # Install Python 3 for vadimcn.vscode-lldb VSCode extension to format debugging info
    && apt-get install -y python3.6 \

Can't start debug after opening the folder in VSCode (MacOS)

Steps to reproduce:

Clone the repository
Open VSCode and "Open Folder in Container"
Press F5 in order to start debugging

VSCode's CodeLLDB extension complains about handshake : "The debugger exited without completing startup handshake."

Log :

Running `cargo build --bin=hello_remote_world --package=hello_remote_world --manifest-path=Cargo.toml --message-format=json`...
   Compiling hello_remote_world v0.1.0 (/workspaces/vscode-remote-try-rust)
    Finished dev [unoptimized + debuginfo] target(s) in 1.07s
Raw artifacts:
{ fileName:
   '/workspaces/vscode-remote-try-rust/target/debug/hello_remote_world',
  name: 'hello_remote_world',
  kind: 'bin' }
Filtered artifacts: 
{ fileName:
   '/workspaces/vscode-remote-try-rust/target/debug/hello_remote_world',
  name: 'hello_remote_world',
  kind: 'bin' }
configuration: { type: 'lldb',
  request: 'launch',
  name: 'Debug executable',
  args: [],
  relativePathBase: '/workspaces/vscode-remote-try-rust',
  program:
   '/workspaces/vscode-remote-try-rust/target/debug/hello_remote_world',
  sourceLanguages: [ 'rust' ] }
/home/vscode/.vscode-server/extensions/vadimcn.vscode-lldb-1.3.0/lldb/bin/lldb: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Error: The debugger exited without completing startup handshake.
--- Checking version ---
{ [Error: spawn lldb ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb',
  path: 'lldb',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-10.0 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-10.0',
  path: 'lldb-10.0',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-9.0 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-9.0',
  path: 'lldb-9.0',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-8.0 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-8.0',
  path: 'lldb-8.0',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-7.0 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-7.0',
  path: 'lldb-7.0',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-6.0 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-6.0',
  path: 'lldb-6.0',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-5.0 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-5.0',
  path: 'lldb-5.0',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-4.0 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-4.0',
  path: 'lldb-4.0',
  spawnargs: [ '-v' ] }
{ [Error: spawn lldb-3.9 ENOENT
	at Process.ChildProcess._handle.onexit (internal/child_process.js:232:19)
	at onErrorNT (internal/child_process.js:407:16)
	at process._tickCallback (internal/process/next_tick.js:63:19)]
  errno: 'ENOENT',
  code: 'ENOENT',
  syscall: 'spawn lldb-3.9',
  path: 'lldb-3.9',
  spawnargs: [ '-v' ] }
--- Done ---

Slatted

#<head!><h1!><Studio627!>

[T=TR] - NULL~~```

git push does not work inside dev container

Hello,

thanks for providing the rust dev container. I only have one problem:

Inside the dev container I cannot push my git commits. (This works on the same computer/configuration with other dev containers like Go or Python.

I am using Windows 10, wsl2 ubuntu, docker desktop.

Git is configured correctly with the Git Credential Manager (GCM). (The link to wsl2 is also set up correctly; it is working with other dev containers).

At the moment I just do a terminal git push outside of vs code but of course it would be nicer to just use the UI element in vscode inside the dev container window.

Thanks for improving this in the future if possible.

Cannot run devcontainer with company proxy

I'm trying to run https://github.com/microsoft/vscode-remote-try-rust

However I can't get it working inside my company because of a proxy problem. It's an authenticating proxy. I modified the Dockerfile and set the environment variables HTTP_PROXY and HTTPS_PROXY to my company's proxy in the format http://user:password@proxy:8080

However then the following fails:

    Failed to download VS Code Server
    (https://update.code.visualstudio.com/commit:cfa2e218100323074ac1948c885448fdf4de2a7f/server-linux- 
    x64/stable): HTTP 407 - authenticationrequired

I'm not sure what is missing. I can confirm that HTTP_PROXY and HTTPS_PROXY are properly set inside the container because I've checked it using

    echo $HTTP_PROXY

I think it would be very helpful if proxy set up was documented becasue it is quite common inside bigger companies.

Regards
Oliver

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

NEW

HOPE

E

Can't make use of cargo or rustup while container building.

Hello.
For my use case, I need to install a few extra toolchains for cross-compiling.

Trying to call rustup to install the target toochains fails during container build, wether I use rustup or /usr/local/cargo/bin/rustup.
I'm starting to suspect that rustup is not installed until after the image has completed building.
Is this correct?

Is there a recommended workaround?