# SE-0271: Package Manager Resources

**URL:** <https://forums.swift.org/t/se-0271-package-manager-resources/30730>\
**Category:** Proposal Reviews\
**Tags:** packagemanager\
**Created:** [November 12, 2019, 11:26pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730 "2019-11-12T23:26:40Z")\
**Posts on this page:** 20\
**Page:** 3

<div class="post-metadata">

**Author:** ![NeoNacho](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/neonacho/32/1368_2.png) [@NeoNacho](https://forums.swift.org/u/NeoNacho)\
**Post date:** [November 13, 2019, 6:47pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/42 "2019-11-13T18:47:09Z")

</div>

> [@scelis](#):
>
> For example, all of the so-called “multi-purpose file types” listed in the proposal would be ignored and NOT be treated as resources by default. Why force the developer to explicitly exclude these when an implicit exclusion can work just as well?

First note that this is only for files inside targets, the `README` file from your example would presumably be dropped in at the top level and would not be a concern.

The big issue with ignoring certain files based on type is that we would force developers to keep in mind a list of file types which are automatically treated as resources and those which are not. This seemed like a huge cognitive burden and even more frustrating considering that the common case for files in targets will be that they are supposed to be either source files or resources.

---

<div class="post-metadata">

**Author:** ![dnadoba](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dnadoba/32/11438_2.png) [@dnadoba](https://forums.swift.org/u/dnadoba)\
**Post date:** [November 13, 2019, 6:54pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/43 "2019-11-13T18:54:43Z")

</div>

No, you just need to add flags to the Metal Compiler and Linker:

 ![MetalCIKLReference6-000](https://global.discourse-cdn.com/swift/original/2X/b/bbb5715076ce2e55111d73be9fba2ecbd622a404.png)  
Both can be added today as Build Settings of a Target in Xcode:  
 ![MetalCIKLReference6-002](https://global.discourse-cdn.com/swift/original/2X/9/97a507b39727e8af5123419e7b20899b69a34253.png) ![MetalCIKLReference6-004](https://global.discourse-cdn.com/swift/original/2X/2/2e4efd5c54c48939be88eb4ff558c0a6b6926f22.png)

---

<div class="post-metadata">

**Author:** ![NeoNacho](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/neonacho/32/1368_2.png) [@NeoNacho](https://forums.swift.org/u/NeoNacho)\
**Post date:** [November 13, 2019, 6:56pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/44 "2019-11-13T18:56:56Z")

</div>

> [@Karl](#):
>
> One thing that’s still not clear to me: is this also true on Darwin platforms? Will all packages with resources (or whose dependencies may have resources or localisation) have to be built with Xcode on macOS?

Building packages for Apple platforms other than macOS with commandline SwiftPM is already not supported today. Packages which are using resources which can simply be copied, such as image files, will work in commandline SwiftPM, but we are not proposing to handle file types which require processing such as Storyboards or Asset Catalogs.

---

<div class="post-metadata">

**Author:** ![Gabor\_Sebestyen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gabor_sebestyen/32/326_2.png) [@Gabor\_Sebestyen](https://forums.swift.org/u/Gabor_Sebestyen)\
**Post date:** [November 13, 2019, 7:16pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/45 "2019-11-13T19:16:30Z")

</div>

That's unfortunate. I'm working on a project that would allow some kind of web templates to be compiled to HTML during Package build. And it would be awesome if SPM supported this kind of dynamic resource transformation feature.

---

<div class="post-metadata">

**Author:** ![NeoNacho](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/neonacho/32/1368_2.png) [@NeoNacho](https://forums.swift.org/u/NeoNacho)\
**Post date:** [November 13, 2019, 7:22pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/46 "2019-11-13T19:22:22Z")

</div>

This will be something that needs the extensible build tools feature, pitched [here](https://forums.swift.org/t/package-manager-extensible-build-tools/10900).

---

<div class="post-metadata">

**Author:** ![danielctull](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/danielctull/32/1964_2.png) [@danielctull](https://forums.swift.org/u/danielctull)\
**Post date:** [November 13, 2019, 8:00pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/47 "2019-11-13T20:00:44Z")

</div>

Awesome good to know. 🙂

---

<div class="post-metadata">

**Author:** ![Gabor\_Sebestyen](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gabor_sebestyen/32/326_2.png) [@Gabor\_Sebestyen](https://forums.swift.org/u/Gabor_Sebestyen)\
**Post date:** [November 13, 2019, 8:58pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/48 "2019-11-13T20:58:36Z")

</div>

Thanks, good to know!

---

<div class="post-metadata">

**Author:** ![kiel](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kiel/32/1392_2.png) [@kiel](https://forums.swift.org/u/kiel)\
**Post date:** [November 14, 2019, 8:55am UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/49 "2019-11-14T08:55:59Z")

</div>

So the package that Xcode generates for an iOS app (say), would have to specify the compiled asset catalog or compiled storyboards or stringsdict files as Resources rather than the raw, source files?

---

<div class="post-metadata">

**Author:** ![Zhu\_Shengqi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zhu_shengqi/32/1199_2.png) [@Zhu\_Shengqi](https://forums.swift.org/u/Zhu_Shengqi)\
**Post date:** [November 14, 2019, 2:43pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/50 "2019-11-14T14:43:24Z")

</div>

There seems to me some ambiguity regarding the `Bundle.module` API. It actually means `Bundle.currentModuleAssociatedBundle`, although this would mean a much longer name. Any ideas about the improvement of the API naming?

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [November 14, 2019, 2:53pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/51 "2019-11-14T14:53:03Z")

</div>

The `AssociatedBundle` is redundant as it‘s implied from the `Bundle` type. If nothing else then it should be just called `currentModule`.

---

<div class="post-metadata">

**Author:** ![Zhu\_Shengqi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zhu_shengqi/32/1199_2.png) [@Zhu\_Shengqi](https://forums.swift.org/u/Zhu_Shengqi)\
**Post date:** [November 14, 2019, 3:00pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/52 "2019-11-14T15:00:13Z")

</div>

The `currentModule` seems to me that the property refers to a object of type `Module`. This is sort of violating Cocoa's naming guideline. For instance, `NSLocale.currentLocale` is definitely of type `NSLocale`, and the user would be confused if it's another type.

Do you have other similar existing examples in Cocoa/Swift API to support this kind of naming? I really doubt it.

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [November 14, 2019, 3:17pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/53 "2019-11-14T15:17:47Z")

</div>

It‘s a 'current module bundle' like you have the 'main bundle' and other similar static properties. Adding type name at the end of the property name to refer to the type the property will return is redundant. I think `currentLocale` is either just `current` when used in Swift or it seems like an oversight that is no longer fixable without deprecation of the old entry point.

---

<div class="post-metadata">

**Author:** ![Zhu\_Shengqi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zhu_shengqi/32/1199_2.png) [@Zhu\_Shengqi](https://forums.swift.org/u/Zhu_Shengqi)\
**Post date:** [November 14, 2019, 3:22pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/54 "2019-11-14T15:22:32Z")

</div>

> [@DevAndArtist](#):
>
> `currentLocale` is either just `current` when used in Swift

That's exact the point I want to address. `currentLocale` becomes `current` with the type name trimmed from the property because `Locale.current` use the namespace to inform the user of the property's type (`Bundle.main` is another example).

Contrasted to the `Locale.current`, `currentModule` is not an adjective, it's a noun, so it would confuse the user if it's type is not `Module`.

In [Swift.org - API Design Guidelines](https://swift.org/documentation/api-design-guidelines/), the document suggests that we should **Include all the words needed to avoid ambiguity** and **Compensate for weak type information**. So from these rules `Bundle.module` or `Bundle.currentModule` seems rather ambiguous names to me.

---

<div class="post-metadata">

**Author:** ![Karl](https://avatars.discourse-cdn.com/v4/letter/k/34f0e0/32.png) [@Karl](https://forums.swift.org/u/Karl)\
**Post date:** [November 14, 2019, 4:07pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/55 "2019-11-14T16:07:06Z")

</div>

> [@NeoNacho](#):
>
> Building packages for Apple platforms other than macOS with commandline SwiftPM is already not supported today. Packages which are using resources which can simply be copied, such as image files, will work in commandline SwiftPM, but we are not proposing to handle file types which require processing such as Storyboards or Asset Catalogs.

Hmm... that's unfortunate. It means that if I have any dependencies, they also need to avoid using resources if I want to build them from the command line.

Is this just a temporary thing, before we get extensible build tools? My understanding is that system works by loading plugins, which would be a nicer way to do this as it means command-line SwiftPM can also work with resources.

Even if it's only supported on the Mac - _what about_ the Mac? Why limit Mac support to "applications/libraries without certain kinds of resources"?

---

<div class="post-metadata">

**Author:** ![DevAndArtist](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/devandartist/32/287_2.png) [@DevAndArtist](https://forums.swift.org/u/DevAndArtist)\
**Post date:** [November 14, 2019, 5:08pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/56 "2019-11-14T17:08:20Z")

</div>

> [@Zhu\_Shengqi](#):
>
> So from these rules `Bundle.module` or `Bundle.currentModule` seems rather ambiguous names to me.

Well it seems to me that this is more a discussion of personal preference than any ambiguity issue. Those names are fine by me and I speak as non native English speaker.

---

<div class="post-metadata">

**Author:** ![NeoNacho](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/neonacho/32/1368_2.png) [@NeoNacho](https://forums.swift.org/u/NeoNacho)\
**Post date:** [November 14, 2019, 6:00pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/57 "2019-11-14T18:00:40Z")

</div>

Xcode will be able to register well-known file types so that their "source" form can be automatically picked up. See this example from the proposal:

> For example, if Xcode registers `.metal` as a file type and there is a metal file in a target, the package will not need to declare that file in the resources list.

---

<div class="post-metadata">

**Author:** ![NeoNacho](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/neonacho/32/1368_2.png) [@NeoNacho](https://forums.swift.org/u/NeoNacho)\
**Post date:** [November 14, 2019, 6:03pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/58 "2019-11-14T18:03:08Z")

</div>

There is currently no concrete plan to lift this limitation in the future. Note that you can still build those packages on the commandline, but you will have to use `xcodebuild` and not SwiftPM.

---

<div class="post-metadata">

**Author:** ![Zhu\_Shengqi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/zhu_shengqi/32/1199_2.png) [@Zhu\_Shengqi](https://forums.swift.org/u/Zhu_Shengqi)\
**Post date:** [November 14, 2019, 11:05pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/59 "2019-11-14T23:05:35Z")

</div>

You still don't get my point here. What API name would you suggest if we have an interface that means **The (current)module of this bundle** (suppose this is meaningful)? This is one aftermath effect of the ambiguity I'm talking here, and it has nothing to do with personal preference or anyone is a native/nonnative English speaker.

By the way, I really suggest reading the Swift API guideline that I posted as link above before this discussion continues. Otherwise the talk here is meaningless (you are from personal preference perspective, I am referring to potential ambiguity/confusion which may affect future module related APIs).

---

<div class="post-metadata">

**Author:** ![ahti](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/ahti/32/604_2.png) [@ahti](https://forums.swift.org/u/ahti)\
**Post date:** [November 18, 2019, 7:38am UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/60 "2019-11-18T07:38:42Z")

</div>

I like the proposal overall, except for one small aspect:

> On Linux, each such resource bundle will be located next to the built executable that is the ultimate client of the target containing the resources.

There should be a way to customize the folder where resource bundles will be located at compile time (this does not mean SwiftPM should copy the bundles to that folder; it should just influence where the final binary looks for any module resource bundle).

As it stands, it would be annoying to impossible (depending on distribution policies) to package a Swift application (that uses resources, itself or transitively) for inclusion in a distro's packages, since binaries and resource files are normally expected to live in specific, different directories.

This might be considered just a bug-fix, but since it contradicts the proposal text, I'm bringing it up here.

---

<div class="post-metadata">

**Author:** ![NeoNacho](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/neonacho/32/1368_2.png) [@NeoNacho](https://forums.swift.org/u/NeoNacho)\
**Post date:** [November 19, 2019, 8:23pm UTC](https://forums.swift.org/t/se-0271-package-manager-resources/30730/61 "2019-11-19T20:23:28Z")

</div>

I agree. I think we probably should do two things:

- by default, look in all locations specified in [swift-corelibs-foundation/FHS Bundles.md at main · apple/swift-corelibs-foundation · GitHub](https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/FHS%20Bundles.md)
- offer a commandline flag to customise the location

[Previous page](https://forums.swift.org/t/se-0271-package-manager-resources/30730.md?page=2)

[Next page](https://forums.swift.org/t/se-0271-package-manager-resources/30730.md?page=4)
