```#!connect jupyter --kernel-name pythonkernel --kernel-spec python3``` doesn't pick up on systems where python interpreter it is called "python3"

[smoothdeveloper]

Describe the bug

When I try to use: #!connect jupyter --kernel-name pythonkernel --kernel-spec python3

I'm getting this stacktrace

at System.Diagnostics.Process.ForkAndExecProcess(ProcessStartInfo startInfo, String resolvedFilename, String[] argv, String[] envp, String cwd, Boolean setCredentials, UInt32 userId, UInt32 groupId, UInt32[] groups, Int32& stdinFd, Int32& stdoutFd, Int32& stderrFd, Boolean usesTerminal, Boolean throwOnNoExec)
at System.Diagnostics.Process.StartCore(ProcessStartInfo startInfo)
at Microsoft.DotNet.Interactive.Utility.CommandLine.StartProcess(String command, String args, DirectoryInfo workingDir, Action`1 output, Action`1 error, ValueTuple`2[] environmentVariables) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive\Utility\CommandLine.cs:line 173
at Microsoft.DotNet.Interactive.Jupyter.ZMQ.JupyterConnection.CreateKernelProcess(KernelSpec spec, String connectionFilePath) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive.Jupyter\ZMQ\JupyterConnection.cs:line 127
at Microsoft.DotNet.Interactive.Jupyter.ZMQ.JupyterConnection.CreateKernelConnectionAsync(String kernelSpecName) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive.Jupyter\ZMQ\JupyterConnection.cs:line 91
at Microsoft.DotNet.Interactive.Jupyter.JupyterKernelConnector.CreateKernelAsync(String kernelName) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive.Jupyter\JupyterKernelConnector.cs:line 28
at Microsoft.DotNet.Interactive.Jupyter.ConnectJupyterKernelCommand.ConnectKernelsAsync(KernelInvocationContext context, InvocationContext commandLineContext) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive.Jupyter\ConnectJupyterKernelCommand.cs:line 72
at Microsoft.DotNet.Interactive.CompositeKernel.<>c__DisplayClass21_0.<<AddKernelConnector>b__0>d.MoveNext() in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive\CompositeKernel.cs:line 271
--- End of stack trace from previous location ---
at System.CommandLine.NamingConventionBinder.CommandHandler.GetExitCodeAsync(Object returnValue, InvocationContext context)
at System.CommandLine.NamingConventionBinder.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass15_0.<<AddMiddleware>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass19_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location ---
at System.CommandLine.Invocation.InvocationPipeline.<InvokeAsync>g__FullInvocationChainAsync|2_0(InvocationContext context)
at System.CommandLine.Parsing.ParseResultExtensions.InvokeAsync(ParseResult parseResult, IConsole console)
at Microsoft.DotNet.Interactive.Commands.DirectiveCommand.InvokeAsync(KernelInvocationContext context) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive\Commands\DirectiveCommand.cs:line 33
at Microsoft.DotNet.Interactive.Kernel.HandleAsync(KernelCommand command, KernelInvocationContext context) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive\Kernel.cs:line 326
at Microsoft.DotNet.Interactive.KernelCommandPipeline.<BuildPipeline>b__6_0(KernelCommand command, KernelInvocationContext context, KernelPipelineContinuation _) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive\KernelCommandPipeline.cs:line 60
at Microsoft.DotNet.Interactive.KernelCommandPipeline.SendAsync(KernelCommand command, KernelInvocationContext context) in D:\a\_work\1\s\src\Microsoft.DotNet.Interactive\KernelCommandPipeline.cs:line 41

I can probably work around this by altering my environment, but I'm wondering if the code who interprets this command could try python3 if python doesn't work?

Which version of .NET Interactive are you using? (In a notebook, run the #!about magic command. ):

• OS
  • [x] macOS
  • Frontend
  • [x] Visual Studio Code

.NET SDK:
 Version:   7.0.304
 Commit:    7e794e2806

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  13.4
 OS Platform: Darwin
 RID:         osx.13-arm64
 Base Path:   /usr/local/share/dotnet/sdk/7.0.304/

Host:
  Version:      8.0.0-preview.5.23280.8
  Architecture: arm64
  Commit:       bc78804f5d

.NET SDKs installed:
  6.0.400 [/usr/local/share/dotnet/sdk]
  6.0.401 [/usr/local/share/dotnet/sdk]
  6.0.405 [/usr/local/share/dotnet/sdk]
  7.0.100-preview.7.22377.5 [/usr/local/share/dotnet/sdk]
  7.0.100-rc.2.22477.23 [/usr/local/share/dotnet/sdk]
  7.0.102 [/usr/local/share/dotnet/sdk]
  7.0.304 [/usr/local/share/dotnet/sdk]
  8.0.100-preview.5.23303.2 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.8 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.0-preview.7.22376.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.0-rc.2.22476.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 7.0.7 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 8.0.0-preview.5.23302.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.0-preview.7.22375.6 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.0-rc.2.22472.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 7.0.7 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.0-preview.5.23280.8 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  /Users/gauthiersegay/dev/src/github.com/dsyme/guido-learns-fsharp/global.json

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[smoothdeveloper]

If my suggestion is ok, I'll try to get this working in a PR.

[jonsequitur]

@shibbas Should this just be a lookup against an existing kernelspec? I'm not sure I understand what's happening here.

[smoothdeveloper]

I tried a bit (just a bit) to get into the toolchain, but it felt complex to do end to end integration for adjusting what I was looking at; even if the developer documentation is actually pretty good, to explain how to setup the extension in vscode to point to new binaries, or how to deploy the typescript VS extension.

I wonder if some "smoke-test" projects that are easy to debug, in form of command line test projects would help.

I've dealt a bit with Fable codebase (which is also not trivial in terms of integrating with tooling of various ecosystems, etc.) and really liked the approach they use for "quicktest" targets, that makes it easy to focus on specific areas, even for newbie contributors (like me).

https://github.com/fable-compiler/Fable/blob/7311b48f58fa8b83d99a8b7d878e6e6c4266f23a/build.fsx#L834-L836

Using this in fable, I was able to get running in stepping into rust target, hack a bit the compiler code, and see how it affects the quicktest related code, knowing absolutely nothing of that codebase.

If there is a way to run a command line that basically makes the kernel submission to the python kernel, and stepping in the C# codebase, and would watch changes to recompile / run again, it would make the development loop easier.

I believe efforts put into this will increase community involvement.