Can't import two dependencies from single repository about swift-sh HOT 9 OPEN

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.

from swift-sh.

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

from swift-sh.

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!

from swift-sh.

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.

from swift-sh.

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.

from swift-sh.

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)

from swift-sh.

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.

from swift-sh.

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

from swift-sh.

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?

from swift-sh.