Unless I miss something, the new code will err on (require 'ob-csharp)
when dotnet command is not available.
Not quite. But not better either: if the dotnet command is not present,
the variable `org-babel-csharp-default-target-framework' would just be
set to "netnil.0" (as the list of available sdks provided by
`org-babel-csharp--find-dotnet-version' will be nil in this case). This
is a "bogus" value however and we would only recognize that when
evaluating (any) csharp code block. So with some nuance of "graceful
degradation" in mind I explicitly throw if the setup was not able to
find a .NET SDK on the host.
See
https://codeberg.org/buoso/csharp-babel/commit/345e1ea23f39971bdf844e54d94677c9560194de
Is that acceptable? Or would you do it differently?
Thanks for the catch in any case!
Why not simply using org-babel-csharp-default-target-framework now?
Absolutely. This also renders the macro
`test-ob-csharp-system-dotnet-version' obsolete. So I removed it.||
https://codeberg.org/buoso/csharp-babel/commit/386780a88682ca73ebb6120f4c8e22daf4d97340
On 08.06.25 14:31, Ihor Radchenko wrote:
poverobuosodonati<poverobuosodon...@gmail.com> writes:
On the matter: This is not for a reason, and you are of course both
right. Doing something more "advanced" then just hardcoding a fixed
version is definitely a good thing. I was actually also planning to move
over the heuristic I implemented for the tests to the actual module. As
of now, we set the the default framework to the latest available one
that can be discovered on the host system.
Unless I miss something, the new code will err on (require 'ob-csharp)
when dotnet command is not available.
Also, you left
(defvar test-ob-csharp-system-dotnet-version (format "net%s.0" (apply #'max
(org-babel-csharp--find-dotnet-version)))
in the tests.
Why not simply using org-babel-csharp-default-target-framework now?
