Support for wildcard paths in Package.swift?

This doesn't seem to be supported, but it would make Package Manager more flexible. On a small personal project, I'd prefer to dump some pngs and swift files into a folder, and use something like: ".target( name: "MyPackage" path: "Files/*.swift" )" to specify them.

1 Like

That's right, we do not support globbing in file-related APIs of the package manifest. However, if you just specify .target( name: "MyPackage" path: "Files" ), all Swift files in that directory will automatically be part of your target. You can also point to a subfolder using the resources argument to include any files in that directory as resources in your target.

1 Like

path: "" is valid and refers to the package root. (I’m not sure if you need exclude: ["Package.swift"].) With the current release, that should be sufficient to assimilate all Swift files into the target. Newer snapshots could be a little more complicated because things like a read‐me would be picked up as a resource, but it still shouldn’t be too bad.

1 Like

You could just get all the folders using code and generate those target:

import Foundation
import PackageDescription

let commands = try! FileManager.default.contentsOfDirectory(atPath: ...)
// let commands: [String] = [
//   "arch",
//   "basename",
//   "date",
//   "ls",
//   "rm",
// ]

let package = Package(
  name: "coreutils",
  platforms: [.macOS(.v10_11)],
  products: commands.map { Product.executable(name: $0, targets: [$0]) },
  dependencies: [
    .package(url: "https://github.com/apple/swift-argument-parser", from: "0.0.1"),
  ],
  targets: commands.map { 
    Target.target(
      name:$0,
      dependencies: [.product(name: "ArgumentParser", package: "swift-argument-parser")]
    )
  }
)

But this seems like a potential security problem.

2 Likes

I deleted my previous comments, now that I realize there is actually no way to programatically find external depencies because of SPM sandboxing :(

I've been using SPM for a couple days now.

It's fantastic, in comparison to the way we had to manage Frameworks and Libraries using Xcode alone. That's a low bar, though.

I have to say SPM is too heavy for small personal projects. It would be nice if SPM started with the absolute minimum things necessary, and built up from there. Currently, that (ie: developing tiny libraries with it) seems like an afterthought.

One problem is that we have a swift-like format for Package.swift, but no way to use external dependencies without editing it. That means there is no default way to create a Package.swift file that can be copied to multiple projects: each instance will require custom editing: editing that is finicky, since we're editing an actual script, not just a json file or a softlink. If someone wants to use tiny packages, that's going to be painful. SPM should provide a way to import external dependencies without altering Package.swift

Secondly, it doesn't seem like there's an obvious way to 'import' a custom module into package.swift - this means, if I have a folder with a hundred tiny packages, they're all going to be bogged down with duplicated code.

Finally, this lack of wild card support and expectation (face it, thanks to the legwork required to do anything else, in practice the subfolders are an expectation) that there always be source code in subfolders means that a developer using tiny packages is dealing with at least 2x as complicated a directory structure as they need to.

I like SPM, and I can see how my complaints are invalid for many projects (pretty much anything with more a few files, or more than a couple people in a team, anything hosted on the net, which I do realize is SPM's reason-to-be) but I wish its design allowed me to create easy-to-use and easy-to-peruse local packages, even for projects of only a couple swift files.

4 Likes

Seeing as I wrote code to scan a folder, and create a working 'Package.swift' manifest, I decided to make a stand-alone CLI tool.

It can add softlinks and aliases to other Packages as Libraries. I'm not sure I want to put in the work, but it wouldn't be hard to have it also scan for bookmark files, to add GitHub packages.

The original design was to use Foundation to do such things, as shown above.

If you can't because of sandboxing then seems like PackageDescription could provide a function.

Globbing is flaky, it's nicer to use filter and proper logic.

One problem is that we have a swift-like format for Package.swift, but no way to use external dependencies without editing it. That means there is no default way to create a Package.swift file that can be copied to multiple projects: each instance will require custom editing: editing that is finicky, since we're editing an actual script, not just a json file or a softlink. If someone wants to use tiny packages, that's going to be painful. SPM should provide a way to import external dependencies without altering Package.swift

What are you comparing to? It's rare there's easy ways to import dependencies with modern tooling.

1 Like

I gather a major thrust of SPM is to facilitate people to distribute their libraries on the internet. As such, my wishlist is probably an edge case; I don't care much (at the moment) about adding packages that rely on a network connection.

My interest in SPM is in SPM as a replacement for local Xcode projects. Ideally I'd like to store my work using hundreds of tiny packages, nested in my file system. That was almost inconceivable, prior to SPM, when I had to create Frameworks and Libraries by hand, due to the maintenance.

If I'm comparing SPM to anything, it's Python's import system (which has its share of problems, and is probably more comparable to swift as a scripting language anyways).

But the issue isn't pressing for me now, because the tool I made will allow me to shuffle my mini packages around, without too many headaches (ie: I can use softlinks now, instead rewriting relative paths to things, and finalize them when I'm done rearranging things).

1 Like