[swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development
Rick Ballard
rballard at apple.com
Mon Jan 30 20:28:55 CST 2017
Hi Derrick,
This use case can be solved using `pin --branch`.
If you really wanted to, you could also simply add B as a direct dependency of P to specify a branch; there's no need to "nest" the dependency. If P really does depend on B being on a branch, the manifest for P may be the right place to express that. In general, however, I'd expect that the case you're describing is a workflow use-case, and thus should be accomplished with pinning; it seems uncommon that a package would truly depend on one of its indirect dependencies being on a branch.
If you'd like to discuss this further, please reply on the "Package Manager Support for branches" thread, as (if I understand you correctly) your question is about that proposal, not the "Top of Tree development" proposal.
Thanks,
- Rick
> On Jan 27, 2017, at 6:42 PM, Derrick Ho via swift-evolution <swift-evolution at swift.org> wrote:
>
> Boris,
>
> My Intent is to make it easier to develop dependency B. I may want to develop on a feature branch for dependency B so I'd like to use PM to force that to happen.
>
> I don't want to have to cd into the A folder and then cd into B to make that change. I want to control the whole thing from the root git repo
>> On Jan 25, 2017, at 10:40 AM, Boris Buegling via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Hi Derrick,
>>
>> I think you meant to send this as a reply to SE-0149 Package Manager Support for branches, correct?
>>
>> I’m not quite sure about the use case for your described behaviour, can you elaborate a bit more why you would want to override a dependency of A from the manifest of P?
>>
>> If the goal is a temporary override, the proposal already allows that by utilising `pin --branch`.
>>
>> Cheers,
>> Boris
>>
>>> On 25 Jan 2017, at 01:50, Derrick Ho via swift-evolution <swift-evolution at swift.org> wrote:
>>>
>>> It probably is a good idea.
>>>
>>> Perhaps the changes can be done in the Package.swift file but allow nesting of dependencies.
>>>
>>> Suppose your dependency is like this where P is your current project
>>>
>>> P --> A --> B
>>>
>>> Normally P we would describe its dependency on A while B would be abstracted away. In A, there would be another Package.swift file describing its dependency on B.
>>>
>>> However if we add the ability to NEST the dependency graph in P's Package.swift it could serve as an override to the default behavior.
>>>
>>> import PackageDescription
>>>
>>> let package = Package(
>>> name: "P",
>>> targets: [],
>>> dependencies: [
>>> .Package(url: "https://blah.com/A.git",
>>> majorVersion: 1, depdencies: [
>>> .Package(url: "https://blahblah.com/B.git, branch: "test")
>>> ]),
>>>
>>> ]
>>> )
More information about the swift-evolution
mailing list