[swift-evolution] [SPM] Roadmap?

[Rick Ballard]

> On Nov 7, 2017, at 12:34 AM, Cory Benfield <cbenfield at apple.com> wrote:
> 
> 
> 
>> On 6 Nov 2017, at 20:25, Kelvin Ma via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> It’d be great to be able to stick an #include path and a linker flag string into Package.swift instead of creating empty c modules that just include system headers. right now this means you have to use a makefile (or up-arrow in the terminal to get the linker flags back) to compile Swift projects that depend on system libraries.
> 
> While I don’t know that I want to be able to just shove include paths and linker flags into Package.swift, I do think some work should be done with Swift projects that want to link system libraries.
> 
> Right now as Kelvin notes you end up writing a ton of copy-paste Swift packages that all basically have the same form: a Package.swift that lists the name of the .pc file, a package name derived from that, and nothing else. Maybe, if you’re feeling generous, a brew() and/or apt() declaration.
> 
> This is sufficiently repetitious that it would actually be possible to write a service that dynamically generates these on the fly: that is, you could write a service that links libgit2 and that builds a git repo on the fly containing these details and serves it to you, such that you could do git clone https://buildaswiftsystempackage.com/icu-uc.git <https://buildaswiftsystempackage.com/icu-uc.git> and would receive exactly this format for any .pc name.
> 
> Given that it’s so straightforward it’s probably worthwhile having SwiftPM grow the ability to synthesise these itself, rather than requiring users to write these identical modules every time.

I agree that this is an area where we should improve support. This is on my personal list of things to consider for this year, though you don't need to wait for me if you'd like to start hashing out a proposal on the list.


> On Nov 6, 2017, at 12:25 PM, Kelvin Ma <kelvin13ma at gmail.com> wrote:
> 
> On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> – Submodules
> 
> Can you elaborate on exactly what you'd like to see here? Offhand I don't recall seeing any feature requests in this area.
> 
> I think submodules means slightly different things to different people but to me i imagine something like “modules that get compiled together as a unit”, i.e., there are no ABI boundaries between submodules.

This sounds like a language feature, not a package-manager feature per-se (though we'd need to support it in the package manager).

> – Help us manage symbol versioning and availability
> 
> Can you elaborate on what you'd like to see here? 
> 
> I only bring this up because there’s been a lot of talk about library evolution, and it is still easy for you to accidentally break your ABI in an unintended manner as nothing in the compiler really checks this. It’d be nice if the SPM took on a bigger role in checking ABI compatibility.

Swift packages are source-only, so I'm not sure that ABI is a concern right now, but unintended API breakage without a corresponding bump in major semantic version certainly is! We'd love to build tooling that can understand your package's API and make sure you're using versioning correctly (at least for Swift API, if not for other languages we support).

> Something else I think will become important to have in the SPM is a better name conflict resolution system. Right now if you depend on two modules (even indirectly) that have the same name there’s really nothing you can do. The SPM should have something like an “import as” system where we can rebind a conflicting module to a new local name.

Yeah, namespacing in general is something that's come up a number of times, but I think needs to be driven on the language side.

Thanks,

	- Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171113/cb6360ef/attachment.html>