Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What about exposing some commands from the web container to the host only in the editor? #11

Open
biati-digital opened this issue Sep 23, 2023 · 5 comments
Labels
question Further information is requested

Comments

@biati-digital
Copy link
Collaborator

The idea

I was thinking about "exposing" the web container’s php, nvm, mysql, mysqldump, etc. to the host so VS Code and other extensions can use them without having to Install a extension like Dev Containers. I know that Dev Containers and Remote SSH are great, I use Remote SSH a lot but the idea behind DDEV Manager is to help users that are starting or to help some devs that do not use docker and simply want the editor to work the same way as if they had all the tools installed in the host.

Having said that, I’m not sure if it’s a good or bad idea or if I’m over thinking and users should just use Dev Containers

How to do it

This is what I did (really quick test).

1.- In my ddev project i created a folder inside .ddev called exposed-commands
2.- Inside this folder I created some basic bash scripts that will call ddev php, ddev mysql, ddev nvm, etc.
3.- In VS Code I configured terminal.integrated.env.osx (only the workspace settings) to add the folder .ddev/exposed-commands to PATH

That’s it. Now if you open a terminal inside VS Code and run php -v it will use the web container’s PHP. The same for any other command for example mysqldump db > db.sql

The exposed command are only available within VS Code and each workspace (ddev project) can have different configuration.

https://share.cleanshot.com/nG6jFPb1

This exposed commands can be even used in tasks https://share.cleanshot.com/r4cYSF7M

Why adding this to the extension?

Because the functionality is meant to make VS Code and DDEV work seamlessly. The extension will be able to configure everything automatically, we can have some settings to disable this functionality or be able to expose only certain commands from the web container.

There’s probably thousand’s of different extensions that allow the user to configure the path to "composer, php, pest, etc." it's impossible for this extension to configure all of them automatically but we could provide a simple option where the user can define what settings must be updated with the correct path.

For example, the extension https://marketplace.visualstudio.com/items?itemName=ikappas.composer offers the following option composer.executablePath to configure composer's path. We could have settings like this:

"ddevManager.exposeCommands.composer": ["composer.executablePath"],

The last part of the key is the name of the command inside the .ddev/exposed-commands folder and the value is a list of all the settings that will be updated with the correct path. The extension will get the path of the specified command and will update the defined settings but only in that workspace, so each project can have their own config. It should also handle the path correctly depending on the OS (for windows using a traditional installation)

How is this functionality different from the commands that are already included with DDEV?

The included commands ddev php, ddev nvm, etc. are great but it's difficult to make them work with existing VS Code extensions. Take as example the extension Code Runner it's impossible to point it to the web container's PHP using ddev php and even if you manage to point it it will still not work as the extension passes the local path in the host, this path does not exist in the web container so it will fail.

The exposed commands are just a wrapper for existing commands, for example: ddev php or even ddev exec /usr/bin/mysqldump but this new commands will update the passed arguments to convert any host path to a path inside the web container

So in this screenshot https://share.cleanshot.com/WqFbvCDh you can see that the extension Code Runner passes the path to the file in the host /Users/manuel/Library/CloudStorage/Dropbox/Development/Sites/testing/wp-content/testing.php

but the exposed command script will convert it to a path in the web container and the code will be processed correctly
/var/www/html/wp-content/testing.php

Final thoughts

I'm not trying to create a new functionality for DDEV, just trying to find a way to have an easier integration with VS Code for new users. At the end the user should be able to use DDEV without having to worry about how to configure it properly with the editor.

I don't even know if I'm over complicating this (would be surprising as doing this test took me a few minutes but probably because of this I could be missing something important). Maybe the "exposed" commands should be added inside the .vscode folder instead of .ddev as they are only used by this extension and VS Code, it will require more testing but at this point it's just an idea.

Would love your opinion.

@biati-digital biati-digital added the question Further information is requested label Sep 23, 2023
@rpkoller
Copy link

I've already commented over in the thread on the ddev discord a while ago but wanted to leave a comment here as well. for me it is not necessarily "an easier integration with VSCode" only useful to new users exclusively. From my perspective and how i understood the feature it would bridge a gap enabling everyone utilizing any or at least the most common binaries from within a container. for me it would solve a long going problem. i dont want to install node and npm on my host computer and only want to use the version available within a container - same for php on macos meanwhile. even though i never used php on the host but since one or two major revision apple removed php from macos. but for php it is the same if you want to use a php binary for any type of linter or tool it is also required to provide the path to the binary and with that binary only available inside the container those tools are not usable like any node based ones. and from a user experience perspective since it is "sort of" an advanced feature it might be a good idea to make the functionality opt in so that it is an informed decision that someone is activating it for one or more binaries within a project. and i agree it would probably make more sense if the config for the exposed binaries is added to the .vscode folder. but in general a double thumbs up for the idea.

@rpkoller
Copy link

hi, one question is the functionality about tasks providers that got added in 2.2.0

New: Tasks Provider. You can now define tasks that will run directly in the container (or any other project you want), just set the task type to "ddev" and that's it. You'll have full access to the container and all the binaries that live there

the implementation of your proposed idea here exposing some commands from the web container to the host? cuz the only change related to that i was able to find in the composer.json: ed33e16

@biati-digital
Copy link
Collaborator Author

Hi, no, this is not the original idea, this functionality allows users to create VS Code tasks that will run inside the container. I implemented this because I've a few projects that have a lot of task and I needed a clean way to run commands inside the container and in any project I needed (I'm aware of ddev exec but it's not possible to specify the project where you want to run the command and it was faster to implement this than to rewrite all my tasks). Here are some examples:

{
    "label": "List files",
    "type": "ddev",
    "command": "ls -la"
},
{
    "label": "Clear cache in a different project",
    "type": "ddev",
    "command": "drush cache:clear",
    "options": {
        "project": "projectID" // The command will run in the specified DDEV project
    }
},
{
    "label": "Update",
    "type": "ddev",
    "command": "apt-get update",
    "options": {
        "sudo": true
    }
},
{
    "label": "List",
    "type": "ddev",
    "command": "ls -la",
    "options": {
        "dir":  "/var" // directory inside the container. it can be a relative path or you can use for example ${workspaceFolder}/src
    }
},
{
    "label": "Build Astro site",
    "type": "ddev",
    "command": "npx astro build"
},

About the original idea of exposing binaries. I've spent some time doing tests and while it works, currently VS Code has some bugs that prevent the functionality to work reliably.

I'll leave this links as reference.

microsoft/vscode#99878
microsoft/vscode-docs@38653d4
microsoft/vscode#187955

// not working when calling run script from package.json - PATH is not set
microsoft/vscode#186244
microsoft/vscode#196930
microsoft/vscode#171934
microsoft/vscode#178577

The main problem is that VS Code does not respect the configured PATH order, if you have node or php installed in the host it will be used instead of the exposed binary ignoring the configuration. If you run a command from package.json (using the run script action) the PATH is different and again and will run in the host.

So it's working partially, if the command does not exist in the host then the command inside the container it's used correctly but I prefer to wait a little more and hope for the bugs to be fixed soon.

I'm a freelance and I've some projects I need to focus on to make ends meet so i won't be able to dedicate time to the extension for a while but this functionality is my top priority to have a full integration with VS Code, as soon as I have some free time, I'll continue with the tests, check possible workarounds, etc. Once I have something to test, I'll let you know so you can try it before publishing the update in the marketplace.

@rpkoller
Copy link

rpkoller commented Mar 2, 2024

ahhhhh ok, but there is one detail not completely understand. where do you define these tasks. i only see the task definitions section within the composer.json within the extension in ~/.vscode. but if you add tasks there those will be gone on the next update?

and thanks for the extensive explantation! and no rush and pressure at all! your personal jobs and todos are always first. and with those open bugs you've linked it doesnt make any sense to hurry anyway. and also better to wait for those bug to be fixed for those who have binaries like node or php installed on the host. that might just trouble otherwise. and i am happy to test any preview when those bugs are fixed upstream and you yourself have time again. thank you! and have a relaxed weekend and hopeful not too stressful projects ahead.

@biati-digital
Copy link
Collaborator Author

Hi @rpkoller Tasks are a VS Code feature that can be extremely useful (even more when you use compound tasks), this tasks are defined in /.vscode/tasks.json inside your project. Once defined you can use the command palette to run any task you want.

You can find more information about tasks in https://code.visualstudio.com/docs/editor/tasks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants