Default Package without 3rd party LRUCache

[BillPitcher]

Can we have the default package without additional dependencies. And if LRUCache is installed then use it, not the other way around. Many sites need extra management involvement and oversight for each project dependency. I know the horse has bolted on this now, but less is more especially when it's not core.

Thanks

[aehlke]

@DarkDust a thought that occurred to me - I wonder if we could vendor it, yet still have a way to use it as an SPM dependency optionally or by default. But I haven't found a good way to have optional Package.swift configurations.

IMO it's better to vendor the dependency than to have two code paths working with and without it and two sets of behaviors to maintain, though I understand you've contributed that (which is also welcome) so there should be a solution near for @BillPitcher

[DarkDust]

As far as I can tell, traits might be the solution but I have no experience with that so far.

Due to the changes for #347, the use of LRUCache is already optional. The code will fall back to NSCache and I guess most of the time the performance will be similar (after all, the rule parsing is magnitudes more expensive than the cache lookups).

[DarkDust]

I have more concerns about dropping the swift-atomics dependency as a default, since it gives us lock-free atomic (thread-safe) access to the cache instances.

The fallback (already implemented) are locks. On Apple platforms, os_unfair_lock is used which is very fast (but of course slower than atomics) but on all other platforms "fat" locks are used. Maybe the performance penalty isn't that bad, haven't made any measurements yet.

As far as I can tell, we cannot do a dependency that's included when a trait is not defined, that is, there is no .when(notTraits:). https://developer.apple.com/documentation/packagedescription/package/dependency/trait/condition-swift.struct

So, thoughts? Go dependency-less by default, add both (LRUCache and swift-atomics) only via traits, or just do LRUCache via trait and always include swift-atomics? Or some other proposal?

[aehlke]

Thanks for sharing your research. I haven't learned about traits yet. But IMO it's best to have the dependencies as default because they provide the best experience, and people who must review deps will look into it and discover whatever mechanism we end up with for opting out, while people who don't would not necessarily investigate options for making the lib faster without knowing to. Dep reviewers must be the fringe case compared with people who want fast operations.

[DarkDust]

(On second thought, the cache lookups should be more expensive than querying the cache instances, even with fat locks... so me wanting atomics may be over-optimization.)

[DarkDust]

I read some docs and did some tests with Swift Package Management and Traits. It looks like we're out of luck right now.

• Requires at least Xcode 16.3 (Swift 6.1).
• In theory, the traits would solve our problem:
  • Define some traits. I've created a LRUCache and an Atomics trait for each dependencies.
  • Define default trait that includes those.
  • Use can chose to override that by doing .package(url: "https://github.com/scinfu/SwiftSoup", from: "x.y", traits: [])
• With swift build it works:
  • It works when the traits: … option is missing: applies the default set and compiles with both dependencies. ✅
  • It works with traits: []: no dependencies are compiled in. ✅
  • It does not work with just one trait, swift build then creates strange errors about not being to find some product in the other dependency. ❌
    • Probably not a big deal. Hopefully the SwiftPM folks fix this eventually.
  • SE-0450 explicitly documents a traits: [.default] and that doesn't work yet. ❌
    • Not a problem for us, IMHO.
• With Xcode it does not work!
  • Even Xcode 26 doesn't support traits yet. ❌
    • At least you cannot specify them in the UI.
    • And instead of applying the default traits set it applies the empty set, thus missing our dependencies.

It's a pity that Xcode completely fails here. This doesn't make traits completely useless, but is a severe problem for this feature for the next several years since the default set cannot be used.

The only other option I've seen are some tricks with environment variables. If really requiring SwiftSoup not to pull in any dependencies is a hard requirement for some, this might be something to evaluate as a last resort.