Skip to content

hide_prod_dependencies / hide_other_dependencies / etc #42

@chrisballinger

Description

@chrisballinger

I think I encountered a scenario where it would be useful to have an additional flag beyond // dev for other dependencies, Possibly prod would be a good start, but maybe it could be more flexible and support like hide_${whatever}_dependencies for anything tagged // whatever. I have been prototyping a Swift Package for OpenCV, which uses a binary xcframework dependency. Normally it will point to a remote URL for a tagged release, but if you want to run swift test against local changes, you'd need to comment out the binaryTarget url/checksum and use a local path version instead.

        // Recompute checksum via `swift package --package-path /path/to/opencv compute-checksum /path/to/opencv2.xcframework.zip`
//        .binaryTarget(
//            name: "opencv2",
//            url: "https://github.com/Rightpoint/opencv/releases/download/4.5.1/opencv2-4.5.1-dynamic.xcframework.zip",
//            checksum: "48273710fe03eb6d6a77ca57f96ef7917db395e6c3bc62e2b495df3dc8f1a0a9"
//        ),
        // If you are compiling OpenCV locally, you can uncomment the below block to use a custom copy
        // e.g. `$ python platforms/apple/build_xcframework.py --dynamic build/dynamic-xcframework`
        .binaryTarget(
            name: "opencv2",
            path: "build/dynamic-xcframework/opencv2.xcframework"
        ),

This seems like the perfect candidate for that scenario.

Does this sound like a feature you'd consider merging? And, if so, could someone point me in the right direction for hacking on this? Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions