I have a Metacello configuration like ConfigurationOfAthens and I want to know which packages provides, the result would be :
Athens-Cairo
Athens-CairoPools
Athens-Core
etc.
I tried
(GoferConfigurationReference name: 'ConfigurationOfAthens') packages.
but it is not understood by the system.
It this supported in Pharo 4?
If you want just the package names you could use helper classes to query from a Configuration. And so your query would be
(MTProject
newFromVersion: (ConfigurationOfAthens project version: #development)
inConfiguration: ConfigurationOfAthens) dependenciesFilteredBy: MTPackage.
These MT classes - which sounds like they should belong to Metacello - are not in Metacello package, but currently in Versionner (included by default in Pharo images).
Diving into results reveals that some "MTPackages" has not their corresponding "RPackage" (this could be a bug, or some weird feature in the package representation models). So you would need further filtering:
((MTProject
newFromVersion: (ConfigurationOfAthens project version: #development)
inConfiguration: ConfigurationOfAthens) dependenciesFilteredBy: MTPackage)
select: [ :pkgName |
(RPackageOrganizer default
packageNamed: pkgName name asSymbol
ifAbsent: []) notNil ]
Related
I need to reuse local Swift packages in multiple targets. They are all part of the same workspace which looks something like this
- Workspace
- ProjectA
- TargetA1 depends on PackageA
- TargetA2 depends on PackageA and PackageB
- ProjectB
- TargetB1 depends on PackageA
- ProjectC, etc...
- Modules
- PackageA
- PackageB
The package build products are added under the individual targets General > Frameworks and Libraries dependencies. Now when I trigger the build, I get
Multiple commands produce '.../Modules/PackageA' etc...
which is somewhat understandable, I hoped Xcode would be smart enough to not build the package over and over again, and even if, I don't understand why that would result in an error in the first place.
Is there a reasonable solution to this?
I don't want to start creating static library targets again or create a separate repository just to be able to import it via a package dependency.
Ok, I found a somewhat satisfactory answer to this.
First, prevent SPM from choosing the library type itself and declare 2 separate build products in the package you want to share:
...
products: [
.library(name: "PackageA", type: .dynamic, targets: ["PackageA"]),
.library(name: "PackageAStatic", type: .static, targets: ["PackageA"])
],
...
One explicitly .dynamic and the other explicitly .static. Now depending on the target you want to use this package in, link the correct one (either dynamic or static). This seems to resolve this issue for me.
I'm trying to use Swift Package Manager's binaryTarget to include the Stripe xcframework available here https://github.com/stripe/stripe-ios/releases/tag/v19.3.0. The package manager doesn't complain, and lets me link to it, but I can't import it im. I've made a sample repo to show it here https://github.com/martyu/StripePackageTest. Am I missing something?
First of all, your example is not testable because you have forgotten to provide a version tag, so this is not a real package.
Second, and more important, I think you have a misconception about how a package works as a binary target. You seem to think that your Swift Package can contain code that sees the XCFramework. (That's why you are trying to import in the framework module in the Sources code of the package.) That's wrong. It's the app that imports the framework module. The package is merely a way of distributing the framework.
In other words, you can write a source code package or a framework-bearing package. One package cannot be both.
But of course you can write a source code package that depends on a framework-bearing package.
First, you don't need a version tag for it to be "real package". You can specify package dependencies via commit SHA and branch as well. Also you can add local package repos in xcode via file://. Note, this is NOT the same as a local dev override.
I didn't have much luck with swift build but I did get it to work fine by creating an app in Xcode and adding the package to it. I think this is what #matt is getting at. You need to import it into a project (xcode, or another SP) and then xcode will assemble all the dependencies when it ~~builds~~ feels like it.
Here's the modified Package.swift I used. I changed the name to Example (as that's presumably the SDK you are building which depends on Stripe). You can include "Stripe" in the Example library's targets if you want it embedded in its framework. Otherwise the client app just needs to import it as well (via the tickboxes when you add it in Xcode, or via dependencies in another Package.swift).
// swift-tools-version:5.3
// The swift-tools-version declares the minimum version of Swift required to build this package.
import PackageDescription
let package = Package(
name: "Example",
platforms: [
.iOS(.v11)
],
products: [
.library(
name: "Example",
type: .dynamic,
targets: ["Example"]),
.library(
name: "Stripe",
targets: ["Stripe"])
],
dependencies: [],
targets: [
// I thought this was defining the Stripe binaryTarget...
.binaryTarget(name: "Stripe",
url: "https://github.com/stripe/stripe-ios/releases/download/v19.3.0/Stripe.xcframework.zip",
checksum: "fe459dd443beee5140018388fd6933e09b8787d5b473ec9c2234d75ff0d968bd"),
// ... and then linking it to the Example project here via "dependencies" ...
.target(name: "Example", dependencies: ["Stripe"], path: "Sources")
// ... so when I'm in "Example" files, I thought I'd be able to import "Stripe" to them
]
)
With tools like npm we can install a specific version
npm install foo#1.2.0
How do you install a specific version using spago install?
Firstly, that's not what spago install does. Instead of "adding a package to your project", spago install downloads all packages that are currently referenced in your spago.dhall file.
Secondly, the idea with Spago is that you don't choose a specific package version. Instead what you choose is a "snapshot", which is a collection of certain versions of all available packages that are guaranteed to compile and work together. This is a measure intended to prevent version conflicts and versioning hell (and this is similar to how Haskell stack works)
The snapshot is defined in your packages.dhall file, and then you specify the specific packages that you want to use in spago.dhall. The version for each package comes from the snapshot.
But if you really need to install a very specific version of a package, and you really know what you're doing, then you can modify the snapshot itself, which is described in packages.dhall.
By default your packages.dhall file might look something like this:
let upstream =
https://raw.githubusercontent.com/purescript/package-sets/psc-0.13.5-20200103/src/packages.dhall sha256:0a6051982fb4eedb72fbe5ca4282259719b7b9b525a4dda60367f98079132f30
let additions = {=}
let overrides = {=}
in upstream // additions // overrides
This is the default template that you get after running spago new.
In order to override the version for a specific package, add it to the overrides map like this:
let overrides =
{ foo =
upstream.foo // { version = "v1.2.0" }
}
And then run spago install. Spago should pull in version 1.2.0 of the foo package for you.
I have a project that I plan on developing in modules, the final application will be any number of the modules built together based on a configuration. I have a swift package that has all of my common code it it, we can call that the platform package. I then went to create my first feature, this went just fine however when I created the wrapper application to pull in each feature, I got this error from SPM in xcode11:
package 'Platform' is required using a revision-based requirement and it depends on local package
'Feature1', which is not supported.
Looking at the code base for SPM here (line 72)
https://github.com/apple/swift-package-manager/blob/master/Sources/PackageGraph/DependencyResolver.swift
It looks like this is something that is just not supported, the mixing of local and remote dependencies? Is this a limitation of SPM / should I be trying to use another tool for this type of app architecture?
In my case, I was trying to add a package, which I was developing, and its Package.swift contained dependencies of the form:
dependencies: [
.package(path: "../PackageName"),
// etc
Changing the references to specific repos solved the problem:
dependencies: [
.package(path: "http://github.com/..."),
// etc
I have a Swift library with a core module plus optional bonus modules. I would like to use the following directory layout, mapping to exported Swift package names as shown:
Taco/
Source/
Core/ → import Taco
Toppings/ → import TacoToppings
SideDishes/ → import TacoSideDishes
To my eyes, that’s a sensible-looking project layout. However, if I’m reading the docs right, this will pollute the global module namespace with unhelpful names like “Core”. It seems that SwiftPM will only export a module whose name is identical to the directory name, and thus I have to do this:
Taco/
Source/
Taco/
TacoToppings/
TacoSideDishes/
Is there a way to configure Package.swift to use the tidier directory layout above and still export the desired module names?
Alternatively, is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
There is not currently a clean way to do this, but it seems like a reasonable request. I recommend filing an enhancement request at http://bugs.swift.org for it.
There is one "hacky" way you can do this:
Create your sources in the desired internal layout:
Sources/Core
Sources/Toppings
Add additional symbolic links for the desired module names:
ln -s Core Sources/Taco
ln -s Toppings Sources/TacoToppings
Add an exclude directive to the manifest to ignore the non-desired module name:
let package = Package(
name: "Taco",
exclude: ["Sources/Core", "Sources/Toppings"]
)
is it possible to make the Core, Toppings, and SideDishes modules internal to the project, and export them all to the world as one big Taco module?
No, unfortunately there is no way to do this currently, and it requires substantial compiler work to be able to support.