<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Apr 19, 2016 at 1:53 PM Max Howell <<a href="mailto:max.howell@apple.com">max.howell@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> +1 to Daniel's last comment. My biggest issue with SwiftPM usability right now is the lack of two related things:<br>
><br>
> (1) Pure Swift submodules<br>
<br>
I would like this too, (could be implemented as some sort of module namespacing instead since with Swift modules the final binary can be composed of multiple modules so that part is separate), needs buy in from Swift core.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> (2) Inability to organize source files in any way other than module membership<br>
> I'm working on a library that is more of a suite of related-but-also-separable feature sets. In a hypothetical pure Swift submodule world, I could make each feature a submodule of the main library: MyLibrary.Feature1, MyLibrary.Feature2, etc., and express any dependencies between them (maybe ML.Feature3 depends on ML.Feature2). Without that, the closest thing I can achieve is to make each one its own module, using underscore delimited names like MyLibrary_Feature1, which is unappealing.<br>
<br>
Seems like ML is its own package? It’s just you would like a namespace feature. I certainly relate to the ugliness of a naming prefix. Especially with an underscore.<br></blockquote><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Yes, namespaces would solve a lot of problems here that I've currently been looking to submodules for. Especially if those namespaces had visibility specifiers and could be easily imported separately into code that depends on them (i.e., import MyLibrary.Feature2 in a source file without making all of MyLibrary visible there).</span><br></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">There may still be some details to work out there—if the user only uses one small feature from the library, would they have to bring along the entire framework? As opposed to having each feature in its own module, where they would only bring along that feature's framework (and any of its dependencies).</span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> So, to avoid those issues, I resigned to making the entire library one module, but then I have to merge all of the source files across all features into a single folder. Xcode groups make this manageable in the IDE, but my flattened source control view is much harder to manage.<br>
<br>
You can organize code in modules with subfolders currently:<br>
<br>
Sources/MyLibrary/A/a.swift<br>
Sources/MyLibrary/B/b.swift<br>
Sources/MyLibrary/c.swift<br>
<br>
Will give you one `MyLibrary` module composed of a, b and c.swift.<br>
<br>
Or do I misunderstand?<br></blockquote><div><br></div><div>I'll have to try that again. The last time I tried organizing things that way, I ended up with A and B as separate modules; it may have been an early version of SwiftPM that didn't support it, or it may have been an error on my part.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> In my particular use case, I believe pure Swift submodules would be a better answer, but I imagine that there are others who would rather be able to use folders for file organization only within the same module and providing a choice to users to make both possible would increase the complexity of the manifest and the PM implementation.<br>
<br>
Long term we need namespaces or submodules I agree.<br>
<br>
</blockquote></div></div>