<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 8:28 PM, Drew Crawford <<a href="mailto:drew@sealedabstract.com" class="">drew@sealedabstract.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 8, 2016, at 9:20 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">At some later date, maybe we’ll get “swift build --run-tests” or “swift tests --no-build” that simply runs the tests<span class="Apple-converted-space"> </span></span><b class="" style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">without</b><span style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> attempting to do a build. Ok, maybe we will. If it’s a week later, ok. If it’s a month later, ok. If it’s going to be a year away, that becomes a real issue. However, there is no compelling reason to couple this from the start, especially if there is no architectural considerations to worry about.</span></div></blockquote></div><div class=""><br class=""></div><div class="">I think the common case (perhaps it is uncommon for you) is a test-driven implementation loop, where somebody has a failing test, they are working in a text editor or IDE, and they want to know if it the thing they changed caused the tests to pass. This is my workflow when I PR something to Foundation or SwiftPM, and my workflow on other projects.</div></div></div></blockquote><div><br class=""></div><div>I don’t run <i class="">all</i> of my tests when I do this. I re-run the subset that actually apply to what I’m working on. Then before performing a check-in, I re-run all of the tests.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Certainly that could be accomplished via chaining commands instead (e.g. "swift build && swift test") which better supports your workflow although that is slightly more awkward for the common situation.</div></div></blockquote><div><br class=""></div><div>This is only the “common situation” if what I was talking about in earlier posts is true: the testing that is being support here is primary for unit tests only or integration tests that can run as quickly as unit tests. But yes, I’m saying that the proposal should enable that exact scenario as the building block. </div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">But in any case this whole argument feels to me like a bikeshed–we have infinite freedom to support any number of CLI commands, with builds & tests together, separated, in a box, with a fox. This one was elected to support a common workflow, not to the exclusion of all the other things we could do additionally.</div></div></blockquote><div><br class=""></div><div>Again, if it so easy, then why not simply come out of the gate with “build”, “test”, and “run-tests”. Surely we’ve already discussed this with more time then it would be to implement <i class="">if</i> SPM’s architecture is actually going to allow this and that shortcuts are not taken to get the “test” portion working more quickly. Call me jaded by experience with other tools, but whenever I’ve seen shortcuts like these taken, it’s always more work than a simple add of a new command to break what is being treated by the current implementation as an atomic command into two.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">But there is language being used on this point (from several people) like:</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="font-family: HelveticaNeue;" class="">there is no compelling reason to couple this from the start</span></blockquote><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class=""><span style="font-family: HelveticaNeue;" class="">My biggest concern with this proposal, as it stands, is that it isn't considering what I think are some very important details that will shape the way the build-tool works longer-term.</span></div></blockquote><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">For example, before any meaningful work can be done to support different types of test runners, the work is going to need to done to break the build & run tests coupling. In this way, I think the proposal does a disservice because it’s not laying a good foundation to build on, it’s laying a foundation that we already know needs to be broken up.</blockquote><br class=""></div><div class="">I fail to understand how the election of one (first) command line argument has any of these follow-on consequences at all. We are discussing a CLI frontend, not an architecture diagram.</div><div class=""><br class=""></div><div class="">If someone believes we are in danger of laying a bad foundation then that is an important objection, but to understand it we need an argument of the form</div><div class=""><br class=""></div><div class="">1. "swift build -t"</div><div class="">2. ???</div><div class="">3. Therefore, [specific irreversible harm]</div><div class=""><br class=""></div><div class="">Until that is laid out in a way I can follow, I can't make sense of the objection.</div></div></blockquote><br class=""></div><div>I don’t know how else to explain my objection; I’ve done so in at least three different ways, including examples of how a similar design affects my previous team with <i class="">still unsupported</i> behavior in other Apple tools that have the same design as being illustrated here (Rick, I’m reaching out to my old counterparts to see if they have any radars they want followed up with). It’s not irreversible harm, it’s starting the process with unnecessary technical debt. </div><div><br class=""></div><div>Fortunately, this time around we can at least fork the tools to get the support we need, if it doesn’t come (and potentially send the fix back or submit proposals), instead of do what Facebook had to do with xctool.</div><div><br class=""></div><div>-David</div><br class=""></body></html>