I like the idea in principle, but in order for it to work in all cases you would have to embed a lot of different runtimes (I think you only added x64 builds of 2.7 and 3.5). Don't forget that especially for linux people use versions of python with all sorts of different ABI flags, so it's not only the different python versions that have to be added.

The binaries should not be checked in. I think they should be built before this new component each time instead.

Including all the binaries adds a lot of bloat that some people won't want. Have you considered creating this as a separate repo (which could be under the pythonnet organization)? You could use CI to build it, picking up the latest pythonnet binaries from AppVeyor and travis (you have have to add some new builds to get the full set of binaries if you intend to support all python variants that are out there).

Unfortunately i have no enough time to maintain "Binaries" repo project. I know that there are more than 10 actively used build variants for pythonnet. But I can maintain, update and publish only distributions that i will use in my commercial development. Probably someone else can do effort that mentioned by tonyroberts. Currently I work on Ubuntu 16 and Windows, this would be most portable platforms for the near future. I will maintain this reduced binary distribution in my fork.

@dmitriyse would you like if I create a repository "pythonnetbin" in pythonnet for these bundled binaries?

I see that you keep updating your bundles.

Note that I'm also admin on chocolatey for pythonnet package and can add you there.

After updating on chocolatey we need to add binaries on nuget.

My first thought is that Linux and Windows can be separate bundles. Then we can also support manylinux wheels. I'm not sure if this conflicts with your deployment?

Another idea is in the bootstrapper logic to check for all necessary flags (OS, python version, bitness, ABI flags) before loading the corresponding bundle or throwing error about unsupported combination of flags.

I understand that you cannot spend much time on this, but just wanted to have official way of distributing these bundles, since this benefits everyone!

@dmitriyse also do you agree to MIT license for your contribution once we transition to it?

Hi!. Yes, it will be cool to migrate to MIT, so sure.

I performed big research work and finally get it work : autodetection for ubuntu, ubuntu+miniconda, windows.
I can help to somebody with received knowledge and ideas. But i still too busy to support additional use cases.

Main use case of my distribution is to build-in python into some CrossPlatform C# .Net 4.5.1 application.
Current solution is well suited to create nuget package for MSBuild build system, but some additional work required.

Typical scenario will be:

1. nuget package on installation should inject Python.Runtime.dll reference (without copy to output directory) Python.Bootstrapper.dll reference into project and add Python.Runtime.zip file as content file (for copy to output directory).
2. Programmer should add initialize and shutdown code like this:

namespace Python.Bootstrapper.Test
{
    using System;
    using System.IO;

    using Runtime;
    public class Program
    {
        static Program()
        {
            Console.WriteLine("Starting application...");

            // Required to be placed in the static constructor for Mono.
            var loadedLib = PythonRuntimeBootstrapper.DetectPythonAndRegisterRuntime();
            Console.WriteLine($"{loadedLib} runtime loaded.");
        }
        static int Main(string[] args)
        {
            // Mono workaround required to fix AssemblyResolve + EntryPoint class bug.
            // Classes that was referenced from EntryPoint class cannot use assemblies resolved through "AssemblyResolve"
            Action monoWorkaround = () =>
            {
                try
                {
                    PythonEngine.Initialize();

                    try
                    {
                        using (Py.GIL())
                        {
                            dynamic sysModule = Py.Import("sys");
                            Console.WriteLine("Python engine version:");
                            Console.WriteLine(sysModule.version);
                        }
                    }
                    finally
                    {
                        PythonEngine.Shutdown();
                    }
                }
                catch (Exception ex)
                {
                    Console.WriteLine(ex);
                }

            };

            monoWorkaround();

            return 0;
        }
    }
}

3. All other magic will be performed automatically in runtime.

@dmitriyse can you please let me know when is this ready for testing?

I will publish RC bin distribution soon. I found floating bug in 2.2.0-Beta under Mono. Currently I am testing fixes. RC version should be mature enough for production use (at least our product will use it).

RC release ready https://github.com/dmitriyse/pythonnet/releases/tag/v2.2.0-bin-RC
You can freely use it for testing.

@dmitriyse I create a pythonnet organization's repository called pythonnetbin for your binaries:

https://github.com/pythonnet/pythonnetbin

Would it be an option to have this as a separate project and just merge the essential parts here?