Repository: freqtrade/freqtrade
Pull request: Support git and local changes in dev containers
## Summary

This PR fixes the problem with git and changes sync in vs code dev container feature

Solve the issue: #7723

## Quick changelog

- postCreateCommand is changed by adding symlink to freqtrade .env directory from the workspace/freqtrade (to have the install environment in the source folder)
- workspace folder changed from /freqtrade to /workspaces/freqtrade
- local sources mount to /workspaces/freqtrade

## What's new?

Now you can actually develop in a vs code dev container


Problem statement:
VS Code Dev Container has no access to the local source code
## Describe your environment

  * Operating system: Mac OS Ventura 13.0
  * Python Version: [container environment]
  * CCXT version: [container environment]
  * Freqtrade Version: source code in branch develop


## Describe the problem:

I'm not sure if it is a bug or a feature :) but ... I'm using VS Code for development and I noticed that devcontainer.json file is thre. Which is quite a good idea for a new developer like me to start with the project. So, I opened the dev container in vs code. Then I faced the following problem. 
- The code which I see in the dev container is not in sync with my local code
- I have no access to git, so I can not actually develop in this dev container

### Steps to reproduce:

  1. Reopen the dev container in vs code
  2. Edit any file
  3. Reopen local code
  4. No changes on the local
  
### Observed Results:

  * I can not really use the dev container as it is supposed to be used
  * I expect when I change the code, I can also create a branch, and commit and also switch back to local and see the changes locally (as it is designed with vs code dev containers)

### Relevant code exceptions or logs

Note: Please copy/paste text of the messages, no screenshots of logs please.

  ```
   no logs
  ```

Hints from issue discussion:

Commit message: support git and local changes in dev containers #7723

Patch to review:
diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json
index 41b8475ec1b..786d317a602 100644
--- a/.devcontainer/devcontainer.json
+++ b/.devcontainer/devcontainer.json
@@ -11,12 +11,13 @@
     "mounts": [
         "source=freqtrade-bashhistory,target=/home/ftuser/commandhistory,type=volume"
     ],
+    "workspaceMount": "source=${localWorkspaceFolder},target=/workspaces/freqtrade,type=bind,consistency=cached",
     // Uncomment to connect as a non-root user if you've added one. See https://aka.ms/vscode-remote/containers/non-root.
     "remoteUser": "ftuser",
 
-    "postCreateCommand": "freqtrade create-userdir --userdir user_data/",
+    "postCreateCommand": "ln -s /freqtrade/.env /workspaces/freqtrade/.env && freqtrade create-userdir --userdir user_data/",
 
-    "workspaceFolder": "/freqtrade/",
+    "workspaceFolder": "/workspaces/freqtrade",
 
     "settings": {
         "terminal.integrated.shell.linux": "/bin/bash",
@@ -35,5 +36,6 @@
         "davidanson.vscode-markdownlint",
         "ms-azuretools.vscode-docker",
         "vscode-icons-team.vscode-icons",
+        "github.copilot",
     ],
 }


Code review comments:
diff_hunk: @@ -35,5 +36,6 @@
         "davidanson.vscode-markdownlint",
         "ms-azuretools.vscode-docker",
         "vscode-icons-team.vscode-icons",
+        "github.copilot",
path: .devcontainer/devcontainer.json
text: @user1:
while i do like copilot personally - that's clearly too controversial to force onto future developers by default.
everyone can install this on his own within the container - but it should clearly not be part of the default config - at least not at this point.

@author:
Yes your are right. This one I just forgot to clean up, when I was preparing the PR

diff_hunk: @@ -11,12 +11,13 @@
     "mounts": [
         "source=freqtrade-bashhistory,target=/home/ftuser/commandhistory,type=volume"
     ],
+    "workspaceMount": "source=${localWorkspaceFolder},target=/workspaces/freqtrade,type=bind,consistency=cached",
     // Uncomment to connect as a non-root user if you've added one. See https://aka.ms/vscode-remote/containers/non-root.
     "remoteUser": "ftuser",
 
-    "postCreateCommand": "freqtrade create-userdir --userdir user_data/",
+    "postCreateCommand": "ln -s /freqtrade/.env /workspaces/freqtrade/.env && freqtrade create-userdir --userdir user_data/",
path: .devcontainer/devcontainer.json
text: @user1:
the `.env` linking seems wrong (maybe you can explain your reasoning on this??).

Why should we use a virutalenv within a container which has freqtrade installed already (That's the whole point of using the devcontainer - to have all dependencies contained within it).

Assuming you're on windows - then the virtual environment would even be broken (python venv vs. linux docker container).

@author:
Sure, I will try. If you mount the source folder and not the folder from the docker image, you lose the installation, which is done during docker build. So in this case the installation is done in /freqtrade dir, which has the .env. But the local sources don't have it and that is correct since you don't want to install the dependencies all over again on your local machine, neither through this setup.

@author:
So it is kind of a workaround to have the source mounted and the freqtrade command in place

@author:
> Assuming you're on windows - then the virtual environment would even be broken (python venv vs. linux docker container).

It should not be platform specific, because it is a command in a linux container, should work the same on windows and mac and linux


@user1:
the `.env` directory is coming from the host (is mounted) - so this is clearly wrong (you shouldn't activate or use a virtual environment from within the container).

i think IF we're moving the directory from /freqtrade to /workspace/freqtrade - then a simple `pip install --user -e .`on that directory is the proper approach.

@user1:
The correct command to put here (considering the other changes) seems to be `pip install --user -e .`.
That'll make sure the correct freqtrade version is used (not the one in `/freqtrade`).



@author:
Yes, it seems it is the way to go. This is a very good remark.