Skip to content

Add PackageSearchClient #5950

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Dec 16, 2022
Merged

Add PackageSearchClient #5950

merged 1 commit into from
Dec 16, 2022

Conversation

neonichu
Copy link
Contributor

@neonichu neonichu commented Dec 6, 2022

This offers a generic interface which allows clients to find packages via exact matching of registry identities or URLs, as well as search through collections and index if there are no exact matches.

@neonichu neonichu added the WIP Work in progress label Dec 6, 2022
@neonichu neonichu self-assigned this Dec 6, 2022
@neonichu
Copy link
Contributor Author

neonichu commented Dec 6, 2022

@swift-ci please smoke test

@neonichu
Copy link
Contributor Author

neonichu commented Dec 6, 2022

Example results:

  1. Search for "apple.swift-argument-parser"
success([PackageMetadata.Package(identity: apple.swift-argument-parser, location: nil, branches: [], versions: [1.0.3], readmeURL: Optional(https://github.com/apple/swift-argument-parser/raw/main/README.md))])
  1. Search for "networking" with Apple default collection configured
success([PackageMetadata.Package(identity: swift-nio, location: Optional("https://github.com/apple/swift-nio.git"), branches: [], versions: [2.43.1, 2.43.0, 2.42.1, 1.14.4, 1.14.3, 1.14.2], readmeURL: Optional(https://raw.githubusercontent.com/apple/swift-nio/main/README.md))])
  1. Search for "https://github.com/jpsim/yams"
success([PackageMetadata.Package(identity: yams, location: Optional("https://github.com/jpsim/yams"), branches: ["fuzzer", "gh-pages", "main", "nn-key-coding-strategy-2", "rules_xcodeproj", "use-swift-dtoa", "yams-3-branch"], versions: [0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5, 0.2.0, 0.3.0, 0.3.1, 0.3.2, 0.3.3, 0.3.4, 0.3.5, 0.3.6, 0.3.7, 0.4.0, 0.4.1, 0.5.0, 0.6.0, 0.7.0, 1.0.0, 1.0.1, 1.0.2, 2.0.0, 3.0.0, 3.0.1, 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5, 4.0.6, 5.0.0, 5.0.1], readmeURL: Optional(https://github.com/jpsim/yams/raw/main/README.md))])

@neonichu neonichu force-pushed the add-package-metadata branch from 345c97e to 2677d2a Compare December 7, 2022 00:23
@neonichu
Copy link
Contributor Author

neonichu commented Dec 7, 2022

@swift-ci please smoke test


public func findPackages(
_ query: String,
callback: @escaping (Result<[Package], Error>) -> Void
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would be nice to have all new apis adopt async/await if we can

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could do that, but considering the dire state of async/await on CI, I'm not sure if we should proliferate it, yet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious, what are you referring to by "state of async/await on CI"? I was hoping I could try using it in some of the new experimental-destination subcommands, especially after we update ArgumentParser 1.1.4 where AsyncParsableCommand is available. Is there anything I should be aware before I even consider it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't use it at all on macOS CI so far, in case that is necessary, we should avoid it. As long as we can scope the use so that macOS CI still works but just doesn't test a certain feature, that should be fine in my book.

location: $0.location,
versions: $0.versions.map { $0.version },
readmeURL: $0.readmeURL) }
if packages.isEmpty, let error = error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the requirement on both is a bit odd? but perhaps i am missing something

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The idea was to normally report the success for the empty search result, but if we don't get a result via search to provide any previous error. So if the query was a registry ID or URL that caused an error which also did not yield any results through search, we'd see the underlying error.

@tomerd
Copy link
Contributor

tomerd commented Dec 7, 2022

one other thing to add here is that the result can include where (which provider) the metadata came from, I think that can be useful in a UI

@neonichu
Copy link
Contributor Author

neonichu commented Dec 8, 2022

@swift-ci please smoke test

@neonichu
Copy link
Contributor Author

neonichu commented Dec 8, 2022

Looks like 5.6 needs a bit more help:

[1138/1162] Compiling PackageMetadata PackageMetadata.swift
/Users/ec2-user/jenkins/workspace/swift-package-manager-with-xcode-self-hosted-PR-osx/branch-main/swiftpm/Sources/PackageMetadata/PackageMetadata.swift:96:43: error: unable to infer complex closure return type; add explicit type to disambiguate
        let fetchStandalonePackageByURL = { (error: Error?) in
                                          ^
                                                            -> <#Result#> 
/Users/ec2-user/jenkins/workspace/swift-package-manager-with-xcode-self-hosted-PR-osx/branch-main/swiftpm/Sources/PackageMetadata/PackageMetadata.swift:147:48: error: 'nil' requires a contextual type
            return fetchStandalonePackageByURL(nil)

This offers a generic interface which allows clients to find packages via exact matching of registry identities or URLs, as well as search through collections and index if there are no exact matches.
@neonichu neonichu force-pushed the add-package-metadata branch from 2677d2a to 28ec83e Compare December 8, 2022 21:28
@neonichu neonichu marked this pull request as ready for review December 8, 2022 21:28
@neonichu neonichu removed the WIP Work in progress label Dec 8, 2022
@neonichu
Copy link
Contributor Author

neonichu commented Dec 8, 2022

@swift-ci please smoke test

@neonichu
Copy link
Contributor Author

neonichu commented Dec 9, 2022

ugh, looks like our good friend is back :/
Time to revert #5957?

/private/var/folders/pf/p5g2vb2j0yx1x6vlmxdppc700000gn/T/TemporaryDirectory.duPOYz/Foo/Tests/package-nameTests/package_nameTests.swift:9:9: error: cannot find 'XCTAssertEqual' in scope
            XCTAssertEqual(package_name().text, "Hello, World!")
            ^~~~~~~~~~~~~~
    /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/XCTest.framework/Headers/XCTestAssertions.h:117:9: note: macro 'XCTAssertEqual' not imported: function like macros not supported
    #define XCTAssertEqual(expression1, expression2, ...) \
            ^
    error: fatalError
    , output: "", stderr: "Building for debugging...\n[1/3] Compiling package_name package_name.swift\n[2/4] Merging module package_name\n[2/4] Linking package-name\n[4/5] Compiling package_nameTests package_nameTests.swift\n/private/var/folders/pf/p5g2vb2j0yx1x6vlmxdppc700000gn/T/TemporaryDirectory.duPOYz/Foo/Tests/package-nameTests/package_nameTests.swift:9:9: error: cannot find \'XCTAssertEqual\' in scope\n        XCTAssertEqual(package_name().text, \"Hello, World!\")\n        ^~~~~~~~~~~~~~\n/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/XCTest.framework/Headers/XCTestAssertions.h:117:9: note: macro \'XCTAssertEqual\' not imported: function like macros not supported\n#define XCTAssertEqual(expression1, expression2, ...) \\\n        ^\nerror: fatalError\n")"Test Case '-[WorkspaceTests.InitTests testNonC99NameExecutablePackage]' failed (21.897 seconds).Test Suite 'InitTests' failed at 2022-12-08 23:26:38.876.

@neonichu
Copy link
Contributor Author

neonichu commented Dec 9, 2022

@swift-ci please smoke test macOS

neonichu added a commit that referenced this pull request Dec 9, 2022
This reverts commit c6faab7.

The failure showed up again in #5950, so it's not actually gone.
neonichu added a commit that referenced this pull request Dec 9, 2022
This reverts commit c6faab7.

The failure showed up again in #5950, so it's not actually gone.
Copy link
Contributor

@yim-lee yim-lee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to let @compnerd know whenever there is a new module?

Other than that, LGTM

@neonichu
Copy link
Contributor Author

@swift-ci please smoke test windows

@neonichu
Copy link
Contributor Author

Looks like the Windows job wasn't run previously?

@neonichu
Copy link
Contributor Author

Windows error looks unrelated:

C:\Users\swift-ci\jenkins\workspace\swiftpm-PR-windows\llvm-project\llvm\lib\IR\DebugInfoMetadata.cpp(948): error C2429: language feature 'init-statements in if/switch' requires compiler flag '/std:c++17'

@neonichu
Copy link
Contributor Author

@swift-ci please smoke test windows

@neonichu
Copy link
Contributor Author

@swift-ci please smoke test windows

@neonichu
Copy link
Contributor Author

I think we need to let @compnerd know whenever there is a new module?

Was looking into adding the new module to the installer scripts, but actually I am not adding it to the CMake build at all for now, so this should be fine as-is.

@neonichu neonichu merged commit 4d312bd into main Dec 16, 2022
@neonichu neonichu deleted the add-package-metadata branch December 16, 2022 17:37
@compnerd
Copy link
Member

As long as nothing is linking against it and it doesn't diverge functionality, I think that should be fine. But we should keep the platforms in parity - so if we are adding a new module, we should be adding it to the CMake build and the swift-installer-scripts packaging IMO.

@neonichu
Copy link
Contributor Author

I agree with that, but I see this particular change as an extension of the package-collections functionality which was never available on Windows to begin with (probably by mistake). We should address this, but separately from this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants