Skip to content
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

[SR-12266] Improving support for mono-repositories #4585

Closed
swift-ci opened this issue Feb 25, 2020 · 3 comments
Closed

[SR-12266] Improving support for mono-repositories #4585

swift-ci opened this issue Feb 25, 2020 · 3 comments

Comments

@swift-ci
Copy link
Contributor

Previous ID SR-12266
Radar rdar://problem/59752949
Original Reporter mitchdenny (JIRA User)
Type Improvement
Status Resolved
Resolution Duplicate
Additional Detail from JIRA
Votes 0
Component/s Package Manager
Labels Improvement
Assignee None
Priority Medium

md5: 91f3e93f3be2d494d297e23476a519cf

duplicates:

  • SR-3951 Multi-Package Repository Support

Issue Description:

Our team is producing a set of open source libraries using Swift which target iOS and Mac (although in theory they could be used with Swift on Linux also). Our libraries taken together form an SDK that developers can use to access Azure (Microsoft's cloud platform).

Each library provides access to some aspect of the Azure service, e.g. storage, identity, AI etc. In addition to libraries which map to particular Azure services, we also have some common "core" libraries which provide common functionality used across the libraries.

Our team is working out of a mono-repository and we are trying to work out the best path forward for structuring our code and release process. We work in a mono-repo to make it easier for our developers to co-evolve parts of the core library and the library that they are working on in addition to making it easier for our customers to file issues against the SDK as a whole (without having to hunt for a repo in which to file the issue).

We want to support Swift PM but unfortunately it doesn't really seem to support publishing multiple libraries out of a single repository very easily. We want to be able to publish independent versions of our libraries from the same mono-repo and manage the interdependencies between them.

For example, we might publish 1.0.0 of core, then 1.0.0 of storage. Then "service X" comes along which requires us to make some enhancements to our core library, so we end up with core 1.1.0 being published.

A developer might want to depend on "service X" 1.0.0 and storage "1.0.0". We assert that version 1.1.0 of core is backwards compatible so storage should be able to use 1.1.0 of core to resolve the resulting diamond dependency problem.

From the reading that I've done it appears that Swift PM can't support this model because you can only have one Package.swift file in the repository.

Am I missing something? What is the recommended model for shipping multiple Swift PM packages out of a mono repo at staggered cadences?

@swift-ci
Copy link
Contributor Author

Comment by Mitch Denny (JIRA)

I've noticed this proposal:

https://github.com/apple/swift-evolution/blob/master/proposals/0272-swiftpm-binary-dependencies.md

And the PR to the swift-package-packager repository which implements most of the functionality. On the surface this would appear to help. However its not clear how dependencies are treated. Are they bundled in the xcframework file?

@hborla
Copy link
Member

hborla commented Feb 25, 2020

@swift-ci create

@ankitspd
Copy link
Member

Binary dependencies feature is unrelated. That's for distributing pre-built code (generally closed-source). Better support for mono-repo style development is desirable but we haven't had formal design discussions around it on swift-evolution. I'll mark this bug a dupe of SR-3951.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 4, 2022
This issue was closed.
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

No branches or pull requests

3 participants