So I totally applaud the effort to tighten up a transport abstraction that can work across different applications. It’s been a long time frustration of mine that we have several key applications that all tackle the hard problem of getting different computers to talk to one another but do it in different ways or even worse do it pretty much the same way but just different code bases. As a WinRM gem maintainer this sometimes means I have to submit several PRs if i want to see a particular enhancement make its way into these different products.
However, I’d really hope we could do this without creating yet another abstraction. Sure we can learn from our other attempts and make the new one even better but once you start getting into integration, I think we’d all agree that gets messy in the best of code bases. I think Train is the best candidate gem to be the home of this effort. That really is the ultimate objective of that gem. There are also others beyond ourselves who I think are passionate about this effort and would be willing to collaborate and provide feedback.
Train has problems. Its development has been mainly to support one application (inspec) and thus suffers some bias. Maybe we need to take on a major version change to accomplish this effort and break compatibility in several areas (or not). However as you have noted, much of trains implementation is “copy/pasted” from Test-Kitchen so getting those two to work together is a natural and iterative progression from where we are today. I really don’t think you will find much opposition to committing major refactorings to train. The initial steps may be uglier than you like but not unworkable.
In the end whatever it is we come up with will need to be maintained by all of us so there are many I think with a vested interested in making this work. The closer we get to a single transport gem that runs through Inspec, Test-Kitchen, bootstrap plugins, provisioning and perhaps other ruby based tools, the better this world will be to code in.