@koubaa I've added Python installation to CI. Please, rebase your branch.

@koubaa I've added Python installation to CI. Please, rebase your branch.

@lostmsu done. Although I suppose this won't fix the issue testing it locally.

@koubaa Locally, you can go to project settings and set PATH environment variable in the Debug section. I personally just have a setup class in the test project, that I never commit:

[SetUpFixture]
public class LocalTestConfig {
    [OneTimeSetUp]
    public void AssemblySetup()
    {
        Environment.SetEnvironmentVariable("PATH",
            @"C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python37_64\;"
            + Environment.GetEnvironmentVariable("PATH"));

        PythonEngine.PythonHome =
            @"C:\Users\USER\AppData\Local\Programs\Python\Python37";
    }
}

Hm, build still fails to find the library. Let me try to fix it.

@lostmsu I can try what you did locally, but ideally this info can be in the wiki

@lostmsu AssemblySetup didn't work, I debugged and my TestCallBacks SetUp function is called before AssemblySetup. I think the order NUnit runs these is not deterministic and since you can run individual tests from the test explorer I don't think It'll work in general even if it does run that setup first. I'll see if I can figure out how the pythonnet embedding tests sets up the python environment.

All CLA requirements met.

@koubaa you have to manually call TestsRuntimeConfig.Ensure(); in [SetUp] for your tests.

@lostmsu done. tests fail due to the issue with the return value of the Func

@lostmsu these changes are ready and tests pass locally. I don't know what happened to the CI:
https://github.com/pythonnet/codecs/actions/runs/85878219

@lostmsu I thought you said these were the reasons you couldn't take it in the pythonnet repo but you could take it in the codecs repo?

@koubaa the reason not to take in the main repo is that conversion is lossy. E.g. decode followed by encode do not give an identical (or at least identically behaving) object back.

I think genericity is not really necessary on its own, but "unintuitive meaning for standard C# delegate types" is a real problem. I just think making a generic solution is easy enough vs going the route of defining custom function types to circumvent "unintuitive meaning for standard C# delegate types", and forcing everyone to use them with this codec.

@koubaa BTW, we can take this if you target it to custom delegate types instead of Func<object[], object> and other standard ones to avoid confusion. It should be enough for most use cases, users could then just have lambdas forwarding the custom delegate type to whatever type they need. E.g.

delegate object PythonFunction(object[] args);

void Foo(PythonFunction pyFunc) {
  Func<..., object> sharpFunc = (a,b,...) => pyFunc(new object[]{ a, b, ...});
  // use sharpFunc normally
}

In fact, you don't even need a PythonAction, because no return Python functions still return None.

But I strongly suggest to try generalize this using Reflection and Reflection.Emit/LINQ expressions.

@lostmsu I'll keep it my private repo then. I don't know how to accomplish what you're looking for