[swift-evolution-announce] [swift-evolution] [swift-build-dev] [Review] SE-0149 Package Manager Support for Top of Tree development

[Rick Ballard]

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")
>>> ]),
>>> 
>>> ]
>>> )