[swift-evolution] [Pitch] Let's talk about submodules

[Matthew Johnson]

Sent from my iPad

On Feb 21, 2017, at 5:18 AM, Dimitri Racordon <Dimitri.Racordon at unige.ch> wrote:

>> Maybe we should try to collect what people want from submodules first.
> 
> I’d like a simple method to group my sources files into some kind lexical scope. Nothing more actually =D

I think we have very similar desires for a submodule system.  I'm goi to write up some thoughts as soon as I have a chance, but today is very busy so it may not be until tomorrow.

> 
>> The point is, specifying which files belong to which submodules is a build system responsibility, not a language responsibility. This keeps source code portable, avoids boilerplate, and keeps submodule information from being duplicated (and thus potentially becoming inconsistent) in file system structure or build system metadata.
> 
> Although I think this assertion makes a lot of sense, wouldn’t it be better for the language to be a bit more opinionated about that? The problem I foresee is when people will start making frameworks with Xcode while others will opt for SwiftPM. I guess compatibility between the two default architectures could easily become hellish. For instance, building/linking C/C++ libraries is a hell as soon as you have more than a single dependency. Everybody has another system to do build their library (make, cmake, autotools, Xcode, …), and people end up rewriting unified build configuration scripts for whatever tool they use.
> 
> Ideally, I’d prefer an opinionated submodule system that clearly distinguish what is part of a submodule from what is not, would it be filesystem-based (my personal favoured) or meta-data based by the means of a manifest or some other directives within the source files (my personal least favoured).
> 
> I like filesystem-based approaches as they are simple to teach and simple to put in place, with and IDE **as well as** with a simple shell. I personally find Python’s approach to be very successful in that regard. The only improvement I would like for Swift is not having to write a dozen of `import foo.bar.baz.koala` at the beginning of my sources. Maybe that could be achieved if importing one module would also make all the public entities of its submodules visible.
> 
>> I wonder if we should have something like “module manifest” for all of a library’s public submodules, similar to SwiftPM's package manifest. So, strawman syntax…
> 
> 
> Writing manifest files is tedious and error-prone when done by hand, I’ll also add that the usability of language shouldn’t depend on some IDE (yes I’m looking at you Java). Writing one and one only manifest for the top-level module is fine and makes sense (specifying targets, dependencies, ...). But I’d argue that writing one for every submodule would be annoying to create and maintain. Also, I’m not convinced that everything need that much information. The multiple versions of a submodule are probably already stored in some versioning tool and the description will most often be a wordy version of the module’s name.
> 
>> Have the people who want modules tried SPM yet?
> 
> Yes I did and to be honest it is close to a perfect solution for me. It’s mostly filesystem-based, easy to teach and easy put in place. In my dreams, submodules would just be an easier way to bundle a bunch of sources together, than having to manually link modules via a dependency list in their respective in manifest files.
> 
> Best regards,
> Dimitri
>