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.
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.
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.
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?
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?
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.
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.
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, 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.
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"?
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.
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.
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.
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).
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.
