[Pitch] Package Editor Commands

I’m hesitant to add support for a specific git host like GitHub at the moment, mostly because registry support is likely to land in the near future and a command like you describe should search the user’s configured registries instead of trying to form a git URL IMO.

Sorting might be a reasonable addition. I’d be interested in hearing from people about whether they do this frequently in their own projects? At a glance, it seems like most of the packages in the source compatibility suite don’t.

1 Like

IMO sorting is too much work to do manually and enforce within a team, but I'd personally appreciate tool support for it.

1 Like

Given the simplicity of the CocoaPods declarations, we keep those sorted pretty easily. Sorting SPM packages is hard to do manually so I don't do it now, but being able to do it automatically would be appreciated. But sorting is very useful when reading the package and wanting to find a single dependency. In fact, I think it should be the default.

2 Likes

It’s unclear to me how they should be sorted, is it by package name? By owner?

I tend to sort dependencies by purpose or “importance” so that when reviewing dependencies to see if they make sense to keep that there’s some context behind how it’s used in the project

Here’s an example from a shared iOS package:

let dependencies: [Package.Dependency] = [
  /* utilities */
  .package(url: "https://github.com/apple/swift-algorithms", .upToNextMinor(from: "0.0.2")),

  /* networking */
  .package(name: "Apollo", url: "https://github.com/apollographql/apollo-ios", .upToNextMinor(from: "0.34.1")),
  // this is "temporarily" needed to support PP5
  .package(name: "SocketIO" , url: "https://github.com/socketio/socket.io-client-swift", .upToNextMinor(from: "15.2.0")),

  /* logging */
  .package(url: "https://github.com/apple/swift-log", .upToNextMajor(from: "1.0.0")),

  /* architecture / design patterns */
  .package(url: "https://github.com/quickbirdstudios/XCoordinator", .upToNextMinor(from: "2.0.7")),
  .package(name: "Lottie", url: "https://github.com/airbnb/lottie-ios", .upToNextMinor(from: "3.1.9")),
]

And then for RediStack I have it sorted by API packages first, then network:

dependencies: [
        .package(url: "https://github.com/apple/swift-log.git", from: "1.0.0"),
        .package(url: "https://github.com/apple/swift-metrics.git", "1.0.0" ..< "3.0.0"),
        .package(url: "https://github.com/apple/swift-nio.git", from: "2.0.0")
    ]

Sort by name in the first section, then by URL for unnamed packages. You'd probably just turn off sorting but the rest of us would get useful sorting automatically.

1 Like

As described in the corresponding proposal, existing git URLs over http will automatically (and primarily) be parsed as a registry endpoint as long as it doesn’t have a .git suffix, and GitHub is very likely to be among the first providers to support this feature. So expressing GitHub repository URLs like this:

dependencies: [
    // Modern Swift API for NSUserDefaults
    .package(name: "SwiftyUserDefaults", url: "https://github.com/sunshinejr/SwiftyUserDefaults", .upToNextMajor("3.1.5")),

    // Delightful console output for Swift developers.
    .package(name: "Rainbow", url: "https://github.com/onevcat/Rainbow", .upToNextMajor("3.1.5")),

    // A powerful framework for developing CLIs in Swift
    .package(name: "SwiftCLI", url: "https://github.com/jakeheis/SwiftCLI", .upToNextMajor("6.0.1")),
 ],

will be applicable for both registry endpoints (if available) and git operations (as a fallback).

I've been thinking it might be possible to avoid adding new flags entirely - If a dependencies list is already sorted, new ones can be inserted in sorted order, and otherwise they can be added at the end. If it was provided as an option and existing dependencies were unsorted, I wouldn't want to rearrange them and discard meaningful whitespace/grouping. I'm not yet sure if it makes sense to formally specify much of this behavior in the proposal, but I'll run some experiments.

2 Likes
Terms of Service

Privacy Policy

Cookie Policy