Improve the first 30-minutes experience

[tonybaloney]

We need to improve the developer experience for the first 30 minutes.

1. The Host Builder assumes a DI container- what happens if they don't have one? What is the simple pattern for a Console Application?
2. You need 3 locators to be multi-platform. Linux and MacOS are hard because you can't just locate then binaries (see related issues).
3. Specifying the "home" path isn't obvious when it's a relative path to the source files.

If anyone else has any thoughts on how things could be easier/simpler to get started please add in the comments.

[NimaAra]

I think the overall experience is good, all I needed was to go through the docs and was up and running in a few minutes.

Here are my 2cents if you need it:

• Requiring a DI container is fine but not needing one is even "finer"
• In my case (and it's specific to my scenario) I care less about the source generated workflow and more about hand written integration.
• I do agree with having to worry about locators, they seem confusing, I would have prefered the .WithPython() to have an option/setting on which I can specify where to find Python rather than using the FromNuget/FromEnvVar etc. Allowing these options on the option/setting would be simpler IMO.
• It is not clear to me why I need .WithHome when I am already providing the paths to the .py files, do all my referenced .py files need to live in the module path?

Also, if I already have a fully set up venv in let's say C:\foo\my-env I am not sure (as of now) where I need to specify that. Is invoking .WithVirtualEnvironment(C:\foo\my-env) enough or do I still need to point to where python is using FromNuget/FromEnvVar etc?

[jmichas]

Well, I don't want to sound like jerk but, I think the first 30m experience is horrible. I'm in more like the first 3h and I still can't get it working.

I am working on MacOS using Rider.

I agree with @NimaAra about using an option pattern with WithPython(). The other extension methods do things that aren't immediately apparent ie appending things to the path supplied.

I am surprised that the FromNuGet() method only supports windows. I tried to create my own to support MacOS but because downstream it appends "bin/xyz" type stuff it doesn't work or requires more work from me overriding all the GetXXX methods in the Locator.

I then tried to just setup my own environment variable but that too gets appended with other path stuff so it fails.

My goal is to provide a .Net MAUI app that wraps some customized Python libraries, but I don't see how I would provide this where Python gets installed with the MAUI app.

Anyway my current tests are just with a simple console app.

[NimaAra]

@jmichas, You do have some control over setting the various required paths. I used the following, you need to set the paths according to your python installation. I suggest you use uv to manage your python installations.

internal sealed class ContainerLocator : PythonLocator
{
    public ContainerLocator() => Version = ServiceCollectionExtensions.ParsePythonVersion("3.12");

    protected override Version Version { get; }

    public override PythonLocationMetadata LocatePython()
    {
        string pythonFolder = "/usr/bin";
        string libPythonPath = "/usr/lib/x86_64-linux-gnu/libpython3.12.so";
        string pythonPath = "/usr/lib/python3.12/lib-dynload";
        string pythonExec = "/usr/bin/python3.12";
        PythonLocationMetadata result = new(pythonFolder, Version, libPythonPath, pythonPath, pythonExec, Debug: true);

        return result;
    }
}

Which you can use as:

...
services
    .AddSingleton<PythonLocator>(new ContainerLocator());

[tonybaloney]

I'm adding a locator that fetches a version of Python for you, this is the same prebuilt site that UV uses.

#323

I'll look at this becoming the default locator, so if you just say WithPython() it'll use this one as it's the most robust and means you can do things like wrapping a Python library and shipping it to nuget without explaining to end users how to install Python