Re: [swift-users] [swift-build-dev] SwiftPM manual dependency management

[Geordie J via swift-users]

Thanks for the update on this one. Judging by the thread, it looks like it’ll 
need to be handled internally by Apple. Also, I have no idea how to reply to 
the existing post without breaking the internet so I’m going to just wait 
patiently instead..

> Am 23.07.2017 um 01:11 schrieb David Sweeris  >:
> 
> 
> On Jul 22, 2017, at 16:09, David Sweeris via swift-build-dev 
> > wrote:
>> 
>> Within the past day or so, someone on evolution rezzed Ted's announcement 
>> thread on the matter.
> 
> Whoops, I was wrong, it's a new thread called "Setting expectations on when 
> we move to Discourse"

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-build-dev] SwiftPM manual dependency management

[David Sweeris via swift-users]

> On Jul 22, 2017, at 16:09, David Sweeris via swift-build-dev 
>  wrote:
> 
> Within the past day or so, someone on evolution rezzed Ted's announcement 
> thread on the matter.

Whoops, I was wrong, it's a new thread called "Setting expectations on when we 
move to Discourse"___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-build-dev] SwiftPM manual dependency management

[David Sweeris via swift-users]

> On Jul 22, 2017, at 12:07, Geordie J  wrote:
> 
> 
>> Am 22.07.2017 um 19:46 schrieb David Sweeris :
>> 
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jul 22, 2017, at 05:16, Geordie Jay via swift-build-dev 
>>>  wrote:
>>> 
>>> How can I get involved in the evolution of this? The evolutions are always 
>>> uneditable uncommentable markdown files on a repo somewhere and the mailing 
>>> lists are in my practical experience inpentrible especially for entries you 
>>> weren't subscribed to the list for, or were "only" subscribed to the digest 
>>> for. I wish they were on google docs or a hackpad equivalent. Is there 
>>> "officially recognised" discussion on the SwiftPM dev slack channel 
>>> regarding evolution topics?
>> 
>> Yeah, I'm not a mailing list fan, either (at least for long or active 
>> threads), and you have nicely summarized the reasons we decided to move to a 
>> discourse server. It's just that it hasn't happened yet.
>> 
>> To answer your question more directly, you can of course discuss things on 
>> slack, twitter, in-person, off-list email, or in any other way, but AFAIK of 
>> you want your conversation to be "on-record", you need to have it on-list. 
>> Until we move to discourse, of course.
>> 
>> I realize that doesn't actually solve the problem, I hope it at least gives 
>> you some moral support.
>> 
>> - Dave Sweeris (who speaks only for himself and shouldn't be taken as 
>> official source of information on this matter)
> 
> This is morale-boosting news! Was this discussed somewhere public? I can 
> hardly wait, and would be willing to put some of my spare time into 
> facilitating the move if that’s at all interesting to those making the 
> decisions on this one.

Yay! morale += 1 

Yeah, I can't remember if it was a formal proposal, but it was discussed 
extensively on the swift-evolution list a while back (maybe late last year or 
early this year, I think?), and the conclusion was that we'd move to Discourse 
(it has a mailing list mode, for the people who prefer that). In any case, I'd 
imagine it hasn't happened yet simply because the people who'd need to be 
involved are slammed with trying to meet the 4.0 release deadline.

Within the past day or so, someone on evolution rezzed Ted's announcement 
thread on the matter. I'd guess that'd be as good a place as any to start, if 
you want to try to get "the ones making the decisions" to let you help.

- Dave Sweeris
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] [swift-build-dev] SwiftPM manual dependency management

[Geordie J via swift-users]

> Am 22.07.2017 um 19:46 schrieb David Sweeris :
> 
> 
> 
> Sent from my iPhone
> 
>> On Jul 22, 2017, at 05:16, Geordie Jay via swift-build-dev 
>>  wrote:
>> 
>> How can I get involved in the evolution of this? The evolutions are always 
>> uneditable uncommentable markdown files on a repo somewhere and the mailing 
>> lists are in my practical experience inpentrible especially for entries you 
>> weren't subscribed to the list for, or were "only" subscribed to the digest 
>> for. I wish they were on google docs or a hackpad equivalent. Is there 
>> "officially recognised" discussion on the SwiftPM dev slack channel 
>> regarding evolution topics?
> 
> Yeah, I'm not a mailing list fan, either (at least for long or active 
> threads), and you have nicely summarized the reasons we decided to move to a 
> discourse server. It's just that it hasn't happened yet.
> 
> To answer your question more directly, you can of course discuss things on 
> slack, twitter, in-person, off-list email, or in any other way, but AFAIK of 
> you want your conversation to be "on-record", you need to have it on-list. 
> Until we move to discourse, of course.
> 
> I realize that doesn't actually solve the problem, I hope it at least gives 
> you some moral support.
> 
> - Dave Sweeris (who speaks only for himself and shouldn't be taken as 
> official source of information on this matter)

This is morale-boosting news! Was this discussed somewhere public? I can hardly 
wait, and would be willing to put some of my spare time into facilitating the 
move if that’s at all interesting to those making the decisions on this one.

Cheers
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] SwiftPM manual dependency management

[Geordie Jay via swift-users]

Hi Ankit, thanks for your explanations.

Ankit Aggarwal  schrieb am Sa. 22. Juli 2017 um
13:44:

> On 22-Jul-2017, at 3:37 PM, Geordie Jay  wrote:
>
>
> Geordie J  schrieb am Fr. 21. Juli 2017 um 14:39:
>
>> Hi Ankit, thanks for your reply.
>>
>> Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users <
>> swift-users@swift.org>:
>>
>>
>>
>> On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users <
>> swift-users@swift.org> wrote:
>>
>>> Hi all,
>>>
>>> My team and I are trying to use SwiftPM to develop a relatively complex
>>> app with multiple dependencies, all of which are being developed locally
>>> and in parallel. The reason for this is compatibility with an existing
>>> module/import structure used by our iOS app. Maybe I’m doing something very
>>> wrong but my experience so far (2 months in) is that this is extremely
>>> difficult with SwiftPM.
>>>
>>> What I’d love to be able to do is to just run `git add submodule
>>> http://blah.com/mysubmodule.git` in the Packages subdirectory and
>>> SwiftPM would just let me manage dependencies from there myself.
>>>
>>> I was excited to see that SwiftPM 4 has a "Top of Tree" development
>>> option for this purpose. So far my experience with this has not been good.
>>> Firstly because SwiftPM *still* unnecessarily tries to clone my repos
>>> itself (some of which are huge), and secondly because this creates an
>>> absolute path dependency in `.build/dependencies-state.json`, meaning this
>>> setup isn’t sharable within our dev team.
>>>
>>> Attempting this with "local" git urls adds an almost absurd level of
>>> complexity, having to tag each commit for SwiftPM to build. The fact that
>>> we'd need to make a commit to test whether the project even builds is
>>> insane enough as is, let alone the tagging and trying to tell the base
>>> project to use a newer minor version etc etc.
>>>
>>> Adding multiple subtargets is also not an option because the
>>> dependencies (as dynamic libraries) really are shared between multiple
>>> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
>>>
>>> *tldr;* *Please* let us manage dependencies ourselves. It’d be so easy
>>> if Package.swift had an option along the lines of *.Package.local(named:
>>> "XYZ")* that it then looked for in ./Packages/XYZ. Again, maybe I’m
>>> overlooking something but this seems like an obvious and vital option to
>>> have. It’d also simplify the introductory SwiftPM docs significantly.
>>>
>>> Is anyone else having this issue? Would this change really be as simple
>>> and painless as it sounds? I would be prepared to make a pull request along
>>> these lines.
>>>
>>
>> I think you're not really using the Top of Tree feature. You need to add
>> each dependency using its canonical URL, hosted at some server like github.
>> After adding the dependencies, you can use edit feature to put a dependency
>> in Top of Tree mode. To do so, run:
>>
>> $ swift package edit  --path
>> ../path/to/self/managed/checkout/of/the/package
>>
>>
>> Yes, this is what I tried this week. I’m pretty sure this is not a case
>> of misunderstanding the feature or the docs.
>>
>>
>> The package manager will then stop using the cloned repository and use
>> the checkout present at that path (regardless of the state it is in).
>>
>>
>> Yes, but then I have – per dependency – two checkouts of a potentially
>> huge repository. Why force everyone on the dev team to clone a huge repo
>> twice, only to *never* use one of the clones. Also, SwiftPM breaks when
>> —path points at Packages/PackageName, which is exactly where I’d expect the
>> package to be, not in some arbitrary external path (+ some kind of internal
>> checkout cache that will never be used) as well.
>>
>> I haven’t tried to test this recently because it’s a slow process but I
>> have the impression the deps could be even be cloned more than twice,
>> depending on how cleverly SwiftPM realises that multiple Packages have the
>> same dependency.
>>
>> Also, this makes managing interdependent state of development amongst
>> dependencies more difficult than needed. How do we guarantee that devs are
>> on the same commit when using top of tree development? Tagging and managing
>> version numbers etc for day-to-day development is emphatically not an
>> option for us. Since SwiftPM packages only work from a git context anyway,
>> why not allow use of git’s established pattern of dealing with this, namely
>> submodules?
>>
>> Sharing this setup is not automatic, but simple. Each user just needs to
>> run the above command once per dependency.
>>
>>
>> We have about 10 dependencies, *all *of which will* always* be in this
>> state. This seems like a lot of overhead and room for user error, plus it’s
>> a huge workaround for something that could be very simple.
>>
>> Also, you only need to do this if you're actively working on a dependency.
>>
>>
>> The point is that we will *always* be 

Re: [swift-users] SwiftPM manual dependency management

[Ankit Aggarwal via swift-users]

> On 22-Jul-2017, at 3:37 PM, Geordie Jay  wrote:
> 
> 
> Geordie J > schrieb am Fr. 21. 
> Juli 2017 um 14:39:
> Hi Ankit, thanks for your reply.
> 
>> Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users 
>> >:
>> 
>> 
>> 
>> On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users 
>> > wrote:
>> Hi all,
>> 
>> My team and I are trying to use SwiftPM to develop a relatively complex app 
>> with multiple dependencies, all of which are being developed locally and in 
>> parallel. The reason for this is compatibility with an existing 
>> module/import structure used by our iOS app. Maybe I’m doing something very 
>> wrong but my experience so far (2 months in) is that this is extremely 
>> difficult with SwiftPM.
>> 
>> What I’d love to be able to do is to just run `git add submodule 
>> http://blah.com/mysubmodule.git`  in the 
>> Packages subdirectory and SwiftPM would just let me manage dependencies from 
>> there myself.
>> 
>> I was excited to see that SwiftPM 4 has a "Top of Tree" development option 
>> for this purpose. So far my experience with this has not been good. Firstly 
>> because SwiftPM still unnecessarily tries to clone my repos itself (some of 
>> which are huge), and secondly because this creates an absolute path 
>> dependency in `.build/dependencies-state.json`, meaning this setup isn’t 
>> sharable within our dev team.
>> 
>> Attempting this with "local" git urls adds an almost absurd level of 
>> complexity, having to tag each commit for SwiftPM to build. The fact that 
>> we'd need to make a commit to test whether the project even builds is insane 
>> enough as is, let alone the tagging and trying to tell the base project to 
>> use a newer minor version etc etc.
>> 
>> Adding multiple subtargets is also not an option because the dependencies 
>> (as dynamic libraries) really are shared between multiple 
>> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
>> 
>> tldr; *Please* let us manage dependencies ourselves. It’d be so easy if 
>> Package.swift had an option along the lines of .Package.local(named: "XYZ") 
>> that it then looked for in ./Packages/XYZ. Again, maybe I’m overlooking 
>> something but this seems like an obvious and vital option to have. It’d also 
>> simplify the introductory SwiftPM docs significantly.
>> 
>> Is anyone else having this issue? Would this change really be as simple and 
>> painless as it sounds? I would be prepared to make a pull request along 
>> these lines.
>> 
>> I think you're not really using the Top of Tree feature. You need to add 
>> each dependency using its canonical URL, hosted at some server like github. 
>> After adding the dependencies, you can use edit feature to put a dependency 
>> in Top of Tree mode. To do so, run:
>> 
>> $ swift package edit  --path 
>> ../path/to/self/managed/checkout/of/the/package
> 
> Yes, this is what I tried this week. I’m pretty sure this is not a case of 
> misunderstanding the feature or the docs.
> 
>> 
>> The package manager will then stop using the cloned repository and use the 
>> checkout present at that path (regardless of the state it is in).
> 
> Yes, but then I have – per dependency – two checkouts of a potentially huge 
> repository. Why force everyone on the dev team to clone a huge repo twice, 
> only to *never* use one of the clones. Also, SwiftPM breaks when —path points 
> at Packages/PackageName, which is exactly where I’d expect the package to be, 
> not in some arbitrary external path (+ some kind of internal checkout cache 
> that will never be used) as well.
> 
> I haven’t tried to test this recently because it’s a slow process but I have 
> the impression the deps could be even be cloned more than twice, depending on 
> how cleverly SwiftPM realises that multiple Packages have the same dependency.
> 
> Also, this makes managing interdependent state of development amongst 
> dependencies more difficult than needed. How do we guarantee that devs are on 
> the same commit when using top of tree development? Tagging and managing 
> version numbers etc for day-to-day development is emphatically not an option 
> for us. Since SwiftPM packages only work from a git context anyway, why not 
> allow use of git’s established pattern of dealing with this, namely 
> submodules?
> 
>> Sharing this setup is not automatic, but simple. Each user just needs to run 
>> the above command once per dependency.
> 
> We have about 10 dependencies, all of which will always be in this state. 
> This seems like a lot of overhead and room for user error, plus it’s a huge 
> workaround for something that could be very simple.
> 
>> Also, you only need to do this if you're actively working on a dependency.
> 
> The point is that we will always be working on the dependencies. 

Re: [swift-users] SwiftPM manual dependency management

[Geordie Jay via swift-users]

Geordie J  schrieb am Fr. 21. Juli 2017 um 14:39:

> Hi Ankit, thanks for your reply.
>
> Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users <
> swift-users@swift.org>:
>
>
>
> On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users <
> swift-users@swift.org> wrote:
>
>> Hi all,
>>
>> My team and I are trying to use SwiftPM to develop a relatively complex
>> app with multiple dependencies, all of which are being developed locally
>> and in parallel. The reason for this is compatibility with an existing
>> module/import structure used by our iOS app. Maybe I’m doing something very
>> wrong but my experience so far (2 months in) is that this is extremely
>> difficult with SwiftPM.
>>
>> What I’d love to be able to do is to just run `git add submodule
>> http://blah.com/mysubmodule.git` in the Packages subdirectory and
>> SwiftPM would just let me manage dependencies from there myself.
>>
>> I was excited to see that SwiftPM 4 has a "Top of Tree" development
>> option for this purpose. So far my experience with this has not been good.
>> Firstly because SwiftPM *still* unnecessarily tries to clone my repos
>> itself (some of which are huge), and secondly because this creates an
>> absolute path dependency in `.build/dependencies-state.json`, meaning this
>> setup isn’t sharable within our dev team.
>>
>> Attempting this with "local" git urls adds an almost absurd level of
>> complexity, having to tag each commit for SwiftPM to build. The fact that
>> we'd need to make a commit to test whether the project even builds is
>> insane enough as is, let alone the tagging and trying to tell the base
>> project to use a newer minor version etc etc.
>>
>> Adding multiple subtargets is also not an option because the dependencies
>> (as dynamic libraries) really are shared between multiple
>> targets/sub-dependencies, which SwiftPM seems to deal with quite well.
>>
>> *tldr;* *Please* let us manage dependencies ourselves. It’d be so easy
>> if Package.swift had an option along the lines of *.Package.local(named:
>> "XYZ")* that it then looked for in ./Packages/XYZ. Again, maybe I’m
>> overlooking something but this seems like an obvious and vital option to
>> have. It’d also simplify the introductory SwiftPM docs significantly.
>>
>> Is anyone else having this issue? Would this change really be as simple
>> and painless as it sounds? I would be prepared to make a pull request along
>> these lines.
>>
>
> I think you're not really using the Top of Tree feature. You need to add
> each dependency using its canonical URL, hosted at some server like github.
> After adding the dependencies, you can use edit feature to put a dependency
> in Top of Tree mode. To do so, run:
>
> $ swift package edit  --path
> ../path/to/self/managed/checkout/of/the/package
>
>
> Yes, this is what I tried this week. I’m pretty sure this is not a case of
> misunderstanding the feature or the docs.
>
>
> The package manager will then stop using the cloned repository and use the
> checkout present at that path (regardless of the state it is in).
>
>
> Yes, but then I have – per dependency – two checkouts of a potentially
> huge repository. Why force everyone on the dev team to clone a huge repo
> twice, only to *never* use one of the clones. Also, SwiftPM breaks when
> —path points at Packages/PackageName, which is exactly where I’d expect the
> package to be, not in some arbitrary external path (+ some kind of internal
> checkout cache that will never be used) as well.
>
> I haven’t tried to test this recently because it’s a slow process but I
> have the impression the deps could be even be cloned more than twice,
> depending on how cleverly SwiftPM realises that multiple Packages have the
> same dependency.
>
> Also, this makes managing interdependent state of development amongst
> dependencies more difficult than needed. How do we guarantee that devs are
> on the same commit when using top of tree development? Tagging and managing
> version numbers etc for day-to-day development is emphatically not an
> option for us. Since SwiftPM packages only work from a git context anyway,
> why not allow use of git’s established pattern of dealing with this, namely
> submodules?
>
> Sharing this setup is not automatic, but simple. Each user just needs to
> run the above command once per dependency.
>
>
> We have about 10 dependencies, *all *of which will* always* be in this
> state. This seems like a lot of overhead and room for user error, plus it’s
> a huge workaround for something that could be very simple.
>
> Also, you only need to do this if you're actively working on a dependency.
>
>
> The point is that we will *always* be working on the dependencies. This
> is the core of what we’re doing, not a short aside. This is what makes me
> think we are either doing something wrong, or there is a big feature gap
> (as it appears from here).
>
> The new manifest also supports using branch instead of version range,
> which is