Can't import two dependencies from single repository

[daveanderson]

#!/usr/bin/swift sh

import Basic     // https://github.com/apple/swift-package-manager.git ~> 0.2.1
import Utility   // https://github.com/apple/swift-package-manager.git ~> 0.2.1

yields

Fatal error: Duplicate values for key: 'SwiftPM'

[mxcl]

Thanks will fix. The work-around is to only specify the comment once per repository.

[daveanderson]

I did try that

#!/usr/bin/swift sh

import Basic     // https://github.com/apple/swift-package-manager.git ~> 0.2.1
import Utility

Which yields

error: product dependency 'Basic' not found

Thanks!

[mxcl]

Yeah that is a different bug which is going to be very to fix. SwiftPM doesn’t vend products that we can depend on named the same as the module names it contains.

I don’t have the bandwidth to fix this in the near future since it will basically involve a rewrite.

[mxcl]

Specifically the target that the script needs to depend on is called SwiftPM, not Basic.

To determine this we can either depend on SwiftPM in swift-sh or parse the output from swift package dump-package. Neither libSwiftPM or the JSON output are stable APIs so… hard choice.

[daveanderson]

In this case Utility depends on Basic so it turns out that the following works:

#!/usr/bin/swift sh

import Utility // https://github.com/apple/swift-package-manager.git ~> 0.3.0
// Note: Basic depends on Utility. The order of these imports is thus significant.
import Basic 

let path = RelativePath("~/Library/Developer") // RelativePath is part of Basic module
print(path.asString)

[mxcl]

I’ve been trying to figure out how we can make this work.

Without depending on libSwiftPM ourselves (which is not stable, so would be a maintenance headache) it is a chicken and egg situation.

We would need to write a Package.swift in order to resolve the deps so that we can write the Package.swift to specify the names of the products that are the dependencies of our script’s executable target.

If you write a Package.swift without any targets, I believe it will resolve the deps still, then we can re-write it correctly after getting product names via dump-package.

Which will likely make build-times slower, oh well.

[mackoj]

I did have a similar issue, I had no such module 'CommandParser' when I did it this way:

import Foundation
import PlatformLookup    // mackoj/SimulatorControl
import CommandParser
import Shell

Here PlatformLookup is the Package name and it's a target within the package.

let package = Package(
  name: "PlatformLookup",
  platforms: [.macOS(.v10_14)],
  products: [
    .executable(name: "cli", targets: ["cli"]),
    .library(name: "CommandParser", targets: ["CommandParser"]),
    .library(name: "SimulatorControl", targets: ["SimulatorControl"]),
    .library(name: "Shell", targets: ["Shell"]),
    .library(name: "PlatformLookup", targets: ["PlatformLookup"]),
  ],
  dependencies: [
    .package(url: "https://github.com/mrackwitz/Version.git", from: "0.7.2")
  ],
  targets: [
    .target(name: "cli", dependencies: ["PlatformLookup", "CommandParser"]),
    .target(
      name: "PlatformLookup",
      dependencies: ["SimulatorControl", "Shell"]
    ), .target(name: "Shell"),
    .target(name: "SimulatorControl", dependencies: ["Version"]),
    .target(name: "CommandParser", dependencies: ["PlatformLookup"]),
    .testTarget(
      name: "PlatformLookupTests",
      dependencies: ["PlatformLookup"]
    ), .testTarget(name: "ShellTests", dependencies: ["Shell"]),
  ],
  swiftLanguageVersions: [.v5]
)

It only worked when I put CommandParser first because I think there is some kind of sorting happening and you should have the first package in alphabetical order do the swift-sh magic import or it won't be loaded.

This was the actual solution.

import Foundation
import CommandParser    // mackoj/SimulatorControl
import PlatformLookup
import Shell

I hope it help @mxcl.

[stefanhp]

The workaround described above are no longer working in version 2.1.0. I updated swift-sh from an earlier version since I'm now using Xcode 12.2 and existing scripts are no longer working with the error: product dependency 'MyModule' in package 'my-module' not found

I have a package that has the following structure (simplified/anonymized):

let package = Package(
    name: "MyModule",
    platforms: [.iOS("11.4"), .macOS("10.13"), .watchOS("4.3")],
    products: [
        .library(name: "MyModule", targets: ["MyModule"]),
        .library(name: "MyModuleExtension", targets: ["MyModuleExtension"]),
    ],
    dependencies: [
        .package(name: "SomeExternalLib", url: "[email protected]:xxx/xxx.git", from: "2.0.5"),
    ],
    targets: [
        .target(name: "MyModule", dependencies: []),
        .target(name: "MyModuleExtension", dependencies: ["MyModule", "SomeExternalLib"]),
    ]
)

Trying to use in a script:

#!/usr/bin/swift sh

import Foundation
import MyModuleExtension // [email protected]:stefanhp/my-module.git == 1.4
import MyModule

print("Hello world!")

It seems that the problem is that the package name MyModule is different from the git path my-module.

If I fork the repo to [email protected]:stefanhp/MyModule.git it works again. But renaming the GitHub repos is not an option because there are a lot of dependencies on them. Maintaining a fork just for swift-sh usage is not very efficient.

Would there be another way to workaround this issue?

Thanks

[thecb4]

I’ve been trying to figure out how we can make this work.

Without depending on libSwiftPM ourselves (which is not stable, so would be a maintenance headache) it is a chicken and egg situation.

We would need to write a Package.swift in order to resolve the deps so that we can write the Package.swift to specify the names of the products that are the dependencies of our script’s executable target.

If you write a Package.swift without any targets, I believe it will resolve the deps still, then we can re-write it correctly after getting product names via dump-package.

Which will likely make build-times slower, oh well.

Would it make sense to do the follow?

`` import ProductName // @mxcl/Path.swift~PackageName/ProductName == 1.0.0 // ^^^^^^^^^^ // makes no assumptions about name alignment. // can parse the info directly into package dependencies and then into dependency for the target. // I chose ~ but another separator could make sense. '#' maybe?