find `code` ide without path

[SvenDowideit]

I switched to using vscode (because trying vscode in browser failed to work), and get

sven$ daytona code

 Opening the project 'daytona' from workspace 'daytona' in your preferred IDE.

ERRO[0002] Please install Visual Studio Code and ensure it's in your PATH. More information on: 'https://code.visualstudio.com/docs/editor/command-line#_launching-from-command-line' 
FATA[0013] exec: "code": executable file not found in $PATH 

which is true - I've got vscode installed on OSX, but it's not in the PATH - and the "More information" link seems mostly Windowsy

while I will go fix that, it would be much more awesome for daytona to go look in some normal places, and magically work.

short term fix:

send the user to https://code.visualstudio.com/docs/setup/mac on OSX

Better, longer term fix

look around in the code ide selection phase - perhaps give the user the advice at that point, and let them choose (imagine for example, someone that has several vscodes installed, because that's what they're writing code for)

[Tpuljak]

@SvenDowideit what do you think about supporting DAYTONA_CODE_PATH as an env that would override simply calling code? This would give the user flexibility to choose exactly where their code binary is located while preventing us from digging around the fs.

We are open to suggestions on what would work best here. We do agree with what you laid out in the issue.

[SvenDowideit]

Manoman - That's a hard question :)

I haven't read the config code yet, so I'm not sure I know what's consistent with the daytona-approach, but over time, I've become wary of using Environment variables as configuration

this specific choice is so specific to a specific desktop, but so far, i also haven't worked out if daytona ide is also specific to a device (which leads me off to the question - can I daytona code to the same workspace from more than one desktop at the same time, using different ide's (and yes, I can - you guys should very much talk that up!!) distracted by #749

mmm, I agree that digging around the fs isn't a good solution - when I dig around NixOS filesystems, or some of my weirder gui container experiments, we'd likely find something bad

I think I have a soft idea that having daytona ide check that the selections the user is considering are possible via the PATH, and letting them over-ride or set it there, thus writing to the ~/.config/daytona/config.json is more my style. That then opens the door for there to be an ideOptions map containing ide profiles that can be random strings with paths and potential cmdline options. (thus allowing the configuration of different vscode userdirs, profiles, extensions, and so on.

Sorry, I think I just made a simple thing even more complicated :)

[Tpuljak]

No worries :) I get what you're aiming at.

We could introduce IDE-specific options. That might be more flexible in the long run as well.

@idagelic thoughts?

[idagelic]

Sounds good - a user-defined IDE map instead of doing the "digging around" would solve the multiple vscode and similar issues