<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><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="">SwiftPM is a pioneer for SwiftPM, and thus we have many modules. For some of these modules I’d like to split them out even more eg:<div class=""><br class=""></div><div class=""><div class="">- Sources</div><div class=""> - Build</div></div><div class=""><br class=""></div><div class="">Build is a module, but really I’d like:</div><div class=""><br class=""></div><div class="">- Sources</div><div class=""> - Build</div><div class=""> - BuildNode</div><div class=""> - BuildDescription</div><div class=""><br class=""></div><div class="">If I do this currently I still will end up with one module: `Build`, this is how the module layout rules that SwiftPM uses work. But instead I’d like Build to be purely an organizational folder and to get two modules *BuildNode* and *BuildDescription*.</div><div class=""><br class=""></div><div class="">I’d like to propose some method to allow further organization, but without ruining our existing rules.</div><div class=""><br class=""></div><div class="">I’d also like to propose tightening up our rules a little.</div><div class=""><br class=""></div><div class="">—————————</div><div class=""><br class=""></div><div class="">One clear way to accomplish the first goal is to extend the rules and say empty folders are not considered modules.</div><div class=""><br class=""></div><div class="">I am unhappy with this however, already there are easy ways to completely transform the build of a package, and the rules we have are somewhat confusing, one can see this in newcomer questions on StackOverflow.</div><div class=""><br class=""></div><div class="">For example:</div><div class=""><br class=""></div><div class="">- Foo</div><div class=""><div class=""> - Sources</div><div class=""> - Bar</div></div><div class=""> - main.swift</div><div class=""><br class=""></div><div class="">Will build a single executable called `Bar`. However if one accidentally creates a new swift file:</div><div class=""><br class=""></div><div class=""><div class="">- Foo</div><div class=""><div class=""> - Sources</div><div class=""> - baz.swift</div><div class=""> - Bar</div></div><div class=""> - main.swift</div></div><div class=""><br class=""></div><div class="">Then you will get a single executable called baz, or more likely a compile error. Diagnosing this is currently an exercise in frustration (though we could improve this with better diagnostics when compiles fail, eg. we could output the modules structure we inferred).</div><div class=""><br class=""></div><div class="">To prevent these transformations we could just tighten up our rules.</div><div class=""><br class=""></div><div class="">If one browses swift packages online there is a clear preference towards a root `Sources` directory.</div><div class=""><br class=""></div><div class="">Thus I propose we only allow</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">A Sources directory with sub folders for modules</li><li class="">A Sources directory with sources directly in the Sources directory and NO sub folders</li></ul><div class=""><br class=""></div></div><div class="">Any other options become errors.</div><div class=""><br class=""></div><div class="">If we then extend the same rules to modules then there will be no surprising behavior. At first I resisted this idea as folders are for organization, however in the new world of SwiftPM *modules* are for organization.</div><div class=""><br class=""></div><div class="">Modules have internal accessibility modifiers that allow powerful architectural designs. Modules have a defined public interface that maps onto folder organizational practices better than </div><div class=""><br class=""></div><div class="">However this prohibits eg:</div><div class=""><br class=""></div><div class="">- NetEngine/</div><div class=""> - CommonCode.swift</div><div class=""> - HTTP/</div><div class=""> - foo.swift</div><div class=""> - HTTPS/</div><div class=""> - bar.swift</div><div class=""><br class=""></div><div class="">And perhaps thus is overly restrictive. Though my argument is that HTTP and HTTPS would be better off being their own modules: it would encourage true encapsulation and a better code architecture.</div><div class=""><br class=""></div><div class="">I am unsure and thus am opening a discussion here. Certainly there are other ways to accomplish the goals here so please let us know what you think a better solution (or not) would be. Thanks for your time.</div><div class=""><br class=""></div><div class="">Max</div></body></html>