Alamofire, URLSessionTaskMetrics, and swift-corelibs-foundation

Currently, the biggest blocker to porting Alamofire to Linux and now Windows is the non-existence of URLSessionTaskMetrics in swift-corelibs-foundation. Most of the other issues have been worked around in an experimental PR, it's just the sheer number of platform checks that would have to be performed to remove URLSessionTaskMetrics that make it unworkable. It appears that porting URLSessionTaskMetrics is fairly low priority for Apple so I'm willing to do the work myself to make Alamofire available on other platforms. My question is, what is the minimal change that would be accepted? Can I create the type (to some degree of equivalence) and enable the proper delegate methods but not make it functional? Alamofire can already handle the fact that metrics may never be returned (thanks watchOS), so it's really just the existence of the type and the delegate methods that we need. How far would I need to go here?

cc @millenomi

4 Likes

Creating the type and the delegate methods but not reporting would in fact be exactly what my patch would be.

1 Like

Thanks. More specifically, what is needed for a PR to be successful? My intention would be to:

  1. Add the URLSessionTaskMetrics and related types matching the 2020 versions. These would live in a URLSessionTaskMetrics.swift file in Sources/FoundationNetworking/URLSession. AFAICT a complete skeleton should be possible.
  2. Add urlSession(_:task:didFinishCollecting:) to URLSessionTaskDelegate.
  3. Add tests? Are there any tests I'd need to implement. Since this will be nonfunctional it doesn't seem like it.

Is there anything I'm missing? Are the directions for Foundation development still correct on the README? It'd be great to just build Foundation and not the entire compiler unless I need to for some reason.

If this seems like a good plan I'll see what I can do this weekend.

That set of to-dos looks correct — you're right that functional tests aren't needed since there is no associated functionality.

(One thing I would ask is for a PR against main, and once that's merged, a PR against release/5.3 that I would nominate to the earliest Swift for Linux monthly once they reprise.)

1 Like

@millenomi Any tips for building just enough of Foundation for me to verify my work? I can't seem to find the right build-script invocation to not build stuff like LLVM. Or do new builds on main always require a full build?

Edit: Forgot to include my invocation:

utils/build-script --skip-build-benchmarks \
  --skip-ios --skip-watchos --skip-tvos --swift-darwin-supported-archs "x86_64" \
  --skip-test-swift --skip-test-lldb --skip-test-xctest --skip-test-libdispatch --skip-test-libicu --skip-test-cmark \
  --cmake-c-launcher="$(which sccache)" --cmake-cxx-launcher="$(which sccache)" \
  --release-debuginfo --test \
  --foundation --xctest \
  --xcode

Sorry, it appears I can just use the Foundation Xcode project itself. (It also appears the full build of the swift project doesn't include FoundationNetworking.)

On Darwin, the FN module is called SwiftFoundationNetworking and the Foundation module SwiftFoundation to avoid clashing with the system modules — but Darwin support in SCF exists for debugging and at-desk work purposes only (SCF doesn’t distribute any build products for Darwin as a platform). You may have to use the other names locally if you’re working there.

I did some work to replicate the Xcode project experience on Linux, but we aren’t there yet. The way I recommend to work on Linux is to use build-script, which, yes, will build everything — but then iterate using CMake invocations, which will not. (See Docs/GettingStarted.md).

My PR is up which includes the type definitions and update to URLSessionTaskDelegate. I'm still setting up a local Linux build and my Darwin build doesn't seem to build SwiftFoundationNetworking, but the Xcode project update builds just fine.

It is now possible to build without LLVM on Swift main, by using a prebuilt Swift trunk toolchain, see the instructions on the pull where I added it a couple months ago. That way, you can just build the corelibs and simply rerun the build-script to rebuild, though you may want to comment out rebuilding libdispatch each time.