How should we approach dependencies abstractions?

[tgrapperon]

Hey everyone!
This is an open question. There are currently two ways to implement dependencies:

• Provide a similar API to the canonical one (either from Apple or Swift)
• Provide an abstraction to this API that is maybe more tailored to modern language features.

I currently adopted the first approach, where I'm exposing similar APIs to Apple's ones. This should allow users to seamlessly adopt these dependencies into their existing projects.

Given how Dependencies works, it is very easy to build powerful abstractions on top of these basic ones. This can be demonstrated by the currently experimental underscored dependencies like _AppStorage or _Notification.

What's bothering me a little is that the keypath the basic dependencies are using is currently the one you would like to use by default for your abstractions.

So, as the library is very new, I'm contemplating namespacing "old-school" dependencies like:

@Dependency(\.system.notificationCenter) var notificationCenter

(system, or standard, or whatever would make more sense here, I'm totally open for alternatives).

Users willing to use this one as @Dependency(\.notificationCenter) would be able to define a computed property directly:

extension DependencyValues {
  public var notificationCenter: NotificationCenter.Dependency {
    get { self.system.notificationCenter }
    set { self.system.notificationCenter = $0 }
  }
}

Other ones would be able to use notificationCenter to build their own abstraction if they want.

So in other words, I'm wondering if we should namespace these "ported" dependencies. We have a very small window of time to act, now that the library is very new, and I would like to know what you think about this.

[JacksonUtsch]

Naming seems to be a common conflict in the Swift world 😭.

One approach could be to create separate libraries for each dependency, then naming would be less significant. (maybe less overhead using imports, additionally it may be debatable about what dependencies to include in the main library, this could mitigate the significance of what dependencies are added) Although, this could seem excessive and less user-friendly.

The prepended system idea could be good. Possibly to match the package you could use @ Dependency(\.additions..

[tgrapperon]

Hey @JacksonUtsch! Thanks for the feedback! (and the sponsoring!). You're right about \.additions, this is something I considered later.

After a few tests, it seems one can shadow a computed property in an external module by another one in the current module. It means for example that you're able to define your own uuid property in DependencyValues in your own (non-modularized) app.
This is however something not really right with Swift, and it may cause issues in a future version. It is also not really clear how this is working when the property is overridden in several external modules. I need to check, but I think a remember a discussion by Slava Pestov on the subject on Twitter, and I think that the conclusion was that this would be something that would need to be fixed at some point.

I wonder if @_disfavoredOverload would work here. I'll experiment with the idea of having both, with a "very weak" non-namespaced one (if this is possible).

Thanks again for the feedback!

[tgrapperon]

It turns out that @_disfavoredOverload works in this case, so I'll probably annotate the dependencies that the library ships, and they should give way if someone redefines them. I'll also provide a fallback way to refer to them if you perform these overloads, likely in some additions namespace as you suggested.
In other words, it seems we'll manage to make it work transparently, which is great news!

[JacksonUtsch]

Seems like an appropriate path to pursue. And thanks for all the open source work!

Do you think it is best to keep all these dependencies in the same library or what is your thinking there? I have a private dependency package but all dependencies are separated out because not all clients use each one.

[tgrapperon]

This is something that I considered, but I think that, for now, the library can benefit from having all these dependencies bundled in the same repo. This allows to maintain a certain degree of coherence between them, and it makes it easier to maintain all of them.

I also feel that having all of them at hand invites to use them. I don't know for example if you'd make the effort to go on GitHub, find back a repo that you know to exists, copy/paste the URL, update your Package.swift accordingly, to finally import BundleInfoDependency to read the bundleIdentifier.

All these dependencies are built upon Apple's frameworks, so they don't require additional dependencies themselves, build relatively fast, and are stripped from final products if unused.
Larger abstractions like AppStorage or Notification may eventually evolve into their own libraries.

I've also experimented with a version that would bundle all the dependencies into the same package, but where each dependency was vending its own product. So you had to explicitly import them into your Package.swift. But the UX was not really good, with very long lists of modules being presented to the user by Xcode.

The current approach still has this kind of flexibility. You depend on DependenciesAdditions, but you can import only BundleInfoDependency at the file level for example. While doing this, you won't see autocompletion for Codable or Compression for example.

As for your private stuff, having them all separated into their own module or their own package is equivalent in terms of isolation, but there are other factors that can justify extracting one in particular, or bundling a few of them into their own package. For example in the music app I'm working on, I have a main "ToolKit/Prelude" that bundles a few common utilities into their own products according to their domain's category, and a "Music" package only products related to this domain (but each one modeling its own sub-domain: chords, scales, notation, etc.). This keeps things nice and isolated, without being too bothersome to maintain.

I'm however open to discussions on the matter!

[JacksonUtsch]

That seems sensible!

Defining core dependencies might help determine the scope of the package. But it all looks good to me as is.