[SPM] Roadmap?

[jechris (JC)]

Hi,

Is there any news about features that are willling to be integrated into
SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a
priority order we should follow.

Regards,

[DevAndArtist (Adrian Meister)]

I’d be happy if we’d get iOS support and submodules :)

···

Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via swift-evolution (swift-evolution@swift.org) schrieb:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[akashivskyy (Adrian Kashivskyy)]

I would like Xcode integration

The last thing I want from a platform-agnostic open-source package manager is built-in integration with a single-platform commercial closed-source IDE.

I think this should be done independently by DT team, without any special favouritism by SPM.

···

——
Adrian Kashivskyy

On 23 Oct 2017, 19:41 +0200, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org>, wrote:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Karl]

Yup. My opinions here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039885.html\. Basically, I think we need support for 1) resources (or ‘assets’) and 2) cross-platform modules.

I think that a better package-manager would really accelerate the Swift ecosystem. We’ve had lots of people complaining about the lack of quality libraries (e.g. for maths and stats) during the Swift 3/4 phases. Personally, I still think it’s too much effort to integrate 3rd-party library projects in to my existing projects and to contribute to them, which is why I usually don’t.

As for Xcode integration: Obviously only Apple can comment on the Xcode roadmap - but I will point out that, like the rest of Swift and LLVM, the package manager is open-source and designed with a library architecture. That means that any IDE could integrate support for SwiftPM, not just Xcode. As users, we can say what we’d like Apple to do with Xcode, but it’s all academic - since SwiftPM doesn’t support bundled assets, it can’t support graphical applications. Bundled assets aren’t just an issue for GUI applications, though - localisation tables, prepared databases and test resources are useful for any kind of package.

So, for me the issue with assets is that some platforms have unique compiled formats (e.g. Apple’s asset catalogues) which support asset variants for localisations and display resolution. Obviously I want my output App to support all of these features. In fact, most modern platforms have support for some kind of asset variants — Apple calls it a TraitCollection, Android calls it a Context — so do we want to support this concept natively somehow in SwiftPM?

I mean, let’s say I have this awesome cross-platform Swift application/library, and I’ve listed some files in my Package.swift and I can find them again at runtime on any platform - all cool. Now, I want to localise my package - what do I do? I’m going to have to create some middleware to translate platform-specific concepts in to a baseline which I can look-up based on some mangling I’m going to create for the file names. Localisation is a problem on servers, too (particularly for error messages), so some idea of asset variants could be something universal-enough to include in the package manager.

- Karl

···

On 23. Oct 2017, at 19:41, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org> wrote:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[gmosx (Georgios Moschovitis)]

I would like to see:

- Xcode integration
  I guess that entails:
  - Support for iOS
  - Support for Assets
- Better error reporting (SPM’s error messages are often cryptic)
- Improve the testing story on Linux (as mentioned elsewhere)

-g.

[rballard (Rick Ballard)]

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Hi all,

(CC-ing swift-build-dev, which is the SwiftPM-specific list and is the best way to get the SwiftPM core team's attention)

The SwiftPM core team has been discussing our plans for SwiftPM 5, and expect to publish a roadmap of the features we're most likely to pursue this year. As always, we welcome proposals and contributions for features the community would most like to see.

Regarding the specific features that have been mentioned in this thread:

– iOS support

I think that this will be best provided by native IDE integration. However, in the meantime, I'd welcome contributions to help improve Xcode's project generation support.

– Xcode integration

I think this will be very important for widespread SwiftPM adoption by the Apple-platform developer community. My previous comments on 2017/6/5 to this list are still the latest word on this:

Xcode 9 lays the groundwork for first-class, native support in Xcode for Swift packages with the preview version of its new build system. This build system provides the flexibility and extensibility needed to allow Xcode to support new build models, such as Swift packages. Additionally, considerable work has gone into the SwiftPM library vended by the SwiftPM project, which will support integrating Swift packages into tools like Xcode.

I'll note that as Xcode's new build system is still a "preview", further work will be needed there before it replaces the old build system. As Xcode is not part of the open source project, forward-looking schedules aren't something I can discuss.

– Build settings and configuration support

The SwiftPM core team has done some work on a proposal for this, and we're looking forward to getting this into a publishable state and discussing it with the community.

– 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.

– Better support for including and linking C libraries

I'd also like to see this, and welcome proposals / contributions.

– A swift test command that can execute arbitrary testing code

As I recall, where the core team had left off on this was a discussion of what testability model were going to propose for SwiftPM (specifically, handling Swift's -enable-testing flag when needed, but minimizing unnecessary rebuilds from using that flag vs. having it off for release builds). IIRC, we were considering explicitly modeling "white box" (which needs -enable-testing) vs "black box" tests. It's been a little while since we last discussed this topic, so if anyone wants this urgently, feel free to start a public conversation about this. Any discussion of this should also involve the XCTest developers (via swift-corelibs-dev).

– Help us manage symbol versioning and availability

Can you elaborate on what you'd like to see here?

– Resources / assets

I think this will be especially important for the iOS developer story, but of course it's useful elsewhere as well. This is definitely on the core team's todo list to write a proposal for at some point.

– Cross-platform modules

Can you elaborate on what you'd like to see here?

– A better C/C++ integration story

The most immediate thing I'm aware of that we're likely to need to do here is to provide some build settings to support C++-specific needs. That said, I'd welcome discussion of other immediate needs here as well.

– Better error reporting (SPM’s error messages are often cryptic)

This is something we made substantial improvements to in SwiftPM 4, so if you haven't upgraded to that release, I'd strongly encourage you to. For other cryptic error messages you encounter, please file reports at bugs.swift.org <Issues · apple/swift · GitHub; – I'd like to see these clarified.

Thanks, all.

  - Rick

···

On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org> wrote:

[hlovatt (Howard Lovatt)]

I would like Xcode integration

-- Howard.

···

On 24 Oct 2017, at 4:43 am, Adrian Zubarev via swift-evolution <swift-evolution@swift.org> wrote:

I’d be happy if we’d get iOS support and submodules :)

Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via swift-evolution (swift-evolution@swift.org) schrieb:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[hartbit (David Hart)]

I think what Howard Lovatt and others are hoping is for SwiftPM to add the few platform-agnostic features which are necessary for the DT team to integrate it as a first-class dependency solution for iOS projects in Xcode (build settings, bundle assets, etc…).

···

On 24 Oct 2017, at 13:46, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:

I would like Xcode integration

The last thing I want from a platform-agnostic open-source package manager is built-in integration with a single-platform commercial closed-source IDE.

I think this should be done independently by DT team, without any special favouritism by SPM.

——
Adrian Kashivskyy

On 23 Oct 2017, 19:41 +0200, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org>, wrote:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[davidbjames (David James)]

I would also +1000 Xcode integration, whoever does it. I’m tired of fighting with command-line mumbo jumbo just to setup and manage dependencies. SPM should pave the way for high-level or junior devs to easily handle their dependencies in the IDE of their choice.

···

On 24 Oct 2017, at 13:46, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:

I would like Xcode integration

The last thing I want from a platform-agnostic open-source package manager is built-in integration with a single-platform commercial closed-source IDE.

I think this should be done independently by DT team, without any special favouritism by SPM.

——
Adrian Kashivskyy

On 23 Oct 2017, 19:41 +0200, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org>, wrote:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

David James

[Karl]

I mean, this is covered by Foundation, so the next step (IMO) would be for Foundation to provide some extensions for SwiftPM which would integrate Locale.

I’m not suggesting SwiftPM should handle localisation natively - just some kind of abstract concept of asset variants which can be resolved at runtime.

- Karl

···

On 28. Oct 2017, at 15:26, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:

Now, I want to localise my package - what do I do? I’m going to have to create some middleware to translate platform-specific concepts in to a baseline which I can look-up based on some mangling I’m going to create for the file names.

[Panajev (Goffredo Marocchi)]

Very well said, I kind of think that at this point in time you do much more for the language by investing into SPM properly than Actors/Coroutines if you had to choose.

···

Sent from my iPhone

On 28 Oct 2017, at 14:26, Karl Wagner via swift-evolution <swift-evolution@swift.org> wrote:

On 23. Oct 2017, at 19:41, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org> wrote:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Yup. My opinions here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039885.html\. Basically, I think we need support for 1) resources (or ‘assets’) and 2) cross-platform modules.

I think that a better package-manager would really accelerate the Swift ecosystem. We’ve had lots of people complaining about the lack of quality libraries (e.g. for maths and stats) during the Swift 3/4 phases. Personally, I still think it’s too much effort to integrate 3rd-party library projects in to my existing projects and to contribute to them, which is why I usually don’t.

As for Xcode integration: Obviously only Apple can comment on the Xcode roadmap - but I will point out that, like the rest of Swift and LLVM, the package manager is open-source and designed with a library architecture. That means that any IDE could integrate support for SwiftPM, not just Xcode. As users, we can say what we’d like Apple to do with Xcode, but it’s all academic - since SwiftPM doesn’t support bundled assets, it can’t support graphical applications. Bundled assets aren’t just an issue for GUI applications, though - localisation tables, prepared databases and test resources are useful for any kind of package.

So, for me the issue with assets is that some platforms have unique compiled formats (e.g. Apple’s asset catalogues) which support asset variants for localisations and display resolution. Obviously I want my output App to support all of these features. In fact, most modern platforms have support for some kind of asset variants — Apple calls it a TraitCollection, Android calls it a Context — so do we want to support this concept natively somehow in SwiftPM?

I mean, let’s say I have this awesome cross-platform Swift application/library, and I’ve listed some files in my Package.swift and I can find them again at runtime on any platform - all cool. Now, I want to localise my package - what do I do? I’m going to have to create some middleware to translate platform-specific concepts in to a baseline which I can look-up based on some mangling I’m going to create for the file names. Localisation is a problem on servers, too (particularly for error messages), so some idea of asset variants could be something universal-enough to include in the package manager.

- Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[jechris (JC)]

Ok so seems to me like there are 2 big needs that came up often on this
thread: better integration for iOS and for C/C++.

For iOS, Build settings would definitely be a huge plus as it would allow
to generate a full configured xcodeproj file (and thus
build/sign/distribute the app). Not perfect but that would pave the way for
next steps.

For C/C++ however I have no idea of what is missing in SPM ecosystem. I
guess build settings would be good interesting, but would it be enough?

Jean-Christophe Pastant

« Mobile Applications Done Right »
156, boulevard Haussmann, 75008 Paris
jcpastant@xebia.fr <youremail@xebia.fr>
[image: Xebia Mobile] <Goto Short Links are no longer available - Google Workspace Admin Help;

···

2017-10-29 22:47 GMT+01:00 Georgios Moschovitis < george.moschovitis@icloud.com>:

I would like to see:

- Xcode integration
  I guess that entails:
  - Support for iOS
  - Support for Assets
- Better error reporting (SPM’s error messages are often cryptic)
- Improve the testing story on Linux (as mentioned elsewhere)

-g.

[taylorswift]

Hi,

Is there any news about features that are willling to be integrated into
SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a
priority order we should follow.

Hi all,

(CC-ing swift-build-dev, which is the SwiftPM-specific list and is the
best way to get the SwiftPM core team's attention)

The SwiftPM core team has been discussing our plans for SwiftPM 5, and
expect to publish a roadmap of the features we're most likely to pursue
this year. As always, we welcome proposals and contributions for features
the community would most like to see.

Regarding the specific features that have been mentioned in this thread:

– *iOS support*

I think that this will be best provided by native IDE integration.
However, in the meantime, I'd welcome contributions to help improve Xcode's
project generation support.

– *Xcode integration*

I think this will be very important for widespread SwiftPM adoption by the
Apple-platform developer community. My previous comments on 2017/6/5 to
this list are still the latest word on this:

Xcode 9 lays the groundwork for first-class, native support in Xcode for
Swift packages with the preview version of its new build system. This build
system provides the flexibility and extensibility needed to allow Xcode to
support new build models, such as Swift packages. Additionally,
considerable work has gone into the SwiftPM library vended by the SwiftPM
project, which will support integrating Swift packages into tools like
Xcode.

I'll note that as Xcode's new build system is still a "preview", further
work will be needed there before it replaces the old build system. As Xcode
is not part of the open source project, forward-looking schedules aren't
something I can discuss.

– *Build settings and configuration support*

The SwiftPM core team has done some work on a proposal for this, and we're
looking forward to getting this into a publishable state and discussing it
with the community.

– *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.

– *Better support for including and linking C libraries*

I'd also like to see this, and welcome proposals / contributions.

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.

– *A swift test command that can execute arbitrary testing code*

As I recall, where the core team had left off on this was a discussion of
what testability model were going to propose for SwiftPM (specifically,
handling Swift's -enable-testing flag when needed, but minimizing
unnecessary rebuilds from using that flag vs. having it off for release
builds). IIRC, we were considering explicitly modeling "white box" (which
needs -enable-testing) vs "black box" tests. It's been a little while since
we last discussed this topic, so if anyone wants this urgently, feel free
to start a public conversation about this. Any discussion of this should
also involve the XCTest developers (via swift-corelibs-dev).

– *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.

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.

···

On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution < swift-evolution@swift.org> wrote:

On Oct 23, 2017, at 10:41 AM, Jean-Christophe Pastant via swift-evolution < > swift-evolution@swift.org> wrote:

[taylorswift]

Since this list is dominated by iDevice developers, as a Linux support
advocate I’d like to see better support for including and linking C
libraries (please no more shim hacks), and a swift test command that can
execute arbitrary testing code. Since library ABI is something that we’re
trying to iron out for Swift 5, I’d also like to see a SPM that helps us
manage symbol versioning and availability.

···

On Mon, Oct 23, 2017 at 2:16 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:

I would like Xcode integration

-- Howard.

On 24 Oct 2017, at 4:43 am, Adrian Zubarev via swift-evolution < > swift-evolution@swift.org> wrote:

I’d be happy if we’d get iOS support and submodules :)

Am 23. Oktober 2017 um 19:41:37, Jean-Christophe Pastant via
swift-evolution (swift-evolution@swift.org) schrieb:

Hi,

Is there any news about features that are willling to be integrated into
SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a
priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[hlovatt (Howard Lovatt)]

To clarify. I meant the infrastructure for IDE integration with Xcode as one of the IDEs that used that infrastructure.

-- Howard.

···

On 24 Oct 2017, at 11:26 pm, David James via swift-evolution <swift-evolution@swift.org> wrote:

I would also +1000 Xcode integration, whoever does it. I’m tired of fighting with command-line mumbo jumbo just to setup and manage dependencies. SPM should pave the way for high-level or junior devs to easily handle their dependencies in the IDE of their choice.

On 24 Oct 2017, at 13:46, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:

I would like Xcode integration

The last thing I want from a platform-agnostic open-source package manager is built-in integration with a single-platform commercial closed-source IDE.

I think this should be done independently by DT team, without any special favouritism by SPM.

——
Adrian Kashivskyy

On 23 Oct 2017, 19:41 +0200, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org>, wrote:
Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

David James

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[Eagle_Offshore]

Without a better C/C++ integration story, Swift is still born in my world.

···

On Oct 28, 2017, at 8:04 AM, Goffredo Marocchi via swift-evolution <swift-evolution@swift.org> wrote:

Very well said, I kind of think that at this point in time you do much more for the language by investing into SPM properly than Actors/Coroutines if you had to choose.

Sent from my iPhone

On 28 Oct 2017, at 14:26, Karl Wagner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On 23. Oct 2017, at 19:41, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

Yup. My opinions here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170918/039885.html\. Basically, I think we need support for 1) resources (or ‘assets’) and 2) cross-platform modules.

I think that a better package-manager would really accelerate the Swift ecosystem. We’ve had lots of people complaining about the lack of quality libraries (e.g. for maths and stats) during the Swift 3/4 phases. Personally, I still think it’s too much effort to integrate 3rd-party library projects in to my existing projects and to contribute to them, which is why I usually don’t.

As for Xcode integration: Obviously only Apple can comment on the Xcode roadmap - but I will point out that, like the rest of Swift and LLVM, the package manager is open-source and designed with a library architecture. That means that any IDE could integrate support for SwiftPM, not just Xcode. As users, we can say what we’d like Apple to do with Xcode, but it’s all academic - since SwiftPM doesn’t support bundled assets, it can’t support graphical applications. Bundled assets aren’t just an issue for GUI applications, though - localisation tables, prepared databases and test resources are useful for any kind of package.

So, for me the issue with assets is that some platforms have unique compiled formats (e.g. Apple’s asset catalogues) which support asset variants for localisations and display resolution. Obviously I want my output App to support all of these features. In fact, most modern platforms have support for some kind of asset variants — Apple calls it a TraitCollection, Android calls it a Context — so do we want to support this concept natively somehow in SwiftPM?

I mean, let’s say I have this awesome cross-platform Swift application/library, and I’ve listed some files in my Package.swift and I can find them again at runtime on any platform - all cool. Now, I want to localise my package - what do I do? I’m going to have to create some middleware to translate platform-specific concepts in to a baseline which I can look-up based on some mangling I’m going to create for the file names. Localisation is a problem on servers, too (particularly for error messages), so some idea of asset variants could be something universal-enough to include in the package manager.

- Karl
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[lukasa (Cory Benfield)]

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 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.

Cory

···

On 6 Nov 2017, at 20:25, Kelvin Ma via swift-evolution <swift-evolution@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.

[trs (Thorsten Seitz)]

+1

-Thorsten

···

Am 25.10.2017 um 21:47 schrieb Howard Lovatt via swift-evolution <swift-evolution@swift.org>:

To clarify. I meant the infrastructure for IDE integration with Xcode as one of the IDEs that used that infrastructure.

-- Howard.

On 24 Oct 2017, at 11:26 pm, David James via swift-evolution <swift-evolution@swift.org> wrote:

I would also +1000 Xcode integration, whoever does it. I’m tired of fighting with command-line mumbo jumbo just to setup and manage dependencies. SPM should pave the way for high-level or junior devs to easily handle their dependencies in the IDE of their choice.

On 24 Oct 2017, at 13:46, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:

I would like Xcode integration

The last thing I want from a platform-agnostic open-source package manager is built-in integration with a single-platform commercial closed-source IDE.

I think this should be done independently by DT team, without any special favouritism by SPM.

——
Adrian Kashivskyy

On 23 Oct 2017, 19:41 +0200, Jean-Christophe Pastant via swift-evolution <swift-evolution@swift.org>, wrote:
Hi,

Is there any news about features that are willling to be integrated into SPM 5?
Those I see the most relevant:
- iOS support
- Some kind of configuration/settings support (debug, release, ...)

I'd like to hear about it from maintainers, especially if there's a priority order we should follow.

Regards,

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

David James

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[rballard (Rick Ballard)]

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 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.

– 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

···

On Nov 7, 2017, at 12:34 AM, Cory Benfield <cbenfield@apple.com> wrote:

On 6 Nov 2017, at 20:25, Kelvin Ma via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Nov 6, 2017, at 12:25 PM, Kelvin Ma <kelvin13ma@gmail.com> wrote:
On Mon, Nov 6, 2017 at 1:00 PM, Rick Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

[pgorzelany (Piotr Gorzelany)]

Any news on the SPM 5 roadmap? It would be great to see iOS support! I think that will lead to a much greater adoption of the package manager across the Swift community and may have a very positive impact on this project since more people may be interested in contributing.