<div><div dir="auto">Hi Ankit, thanks for your explanations.</div><br><div class="gmail_quote"><div dir="auto">Ankit Aggarwal <<a href="mailto:ankit_aggarwal@apple.com">ankit_aggarwal@apple.com</a>> schrieb am Sa. 22. Juli 2017 um 13:44:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 22-Jul-2017, at 3:37 PM, Geordie Jay <<a href="mailto:geojay@gmail.com" target="_blank">geojay@gmail.com</a>> wrote:</div><br class="m_-5119764626795818258Apple-interchange-newline"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class="m_-5119764626795818258Apple-interchange-newline">Geordie J <<a href="mailto:geojay@gmail.com" target="_blank">geojay@gmail.com</a>> schrieb am Fr. 21. Juli 2017 um 14:39:<br></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Hi Ankit, thanks for your reply.<div><br><div></div></div></div><div style="word-wrap:break-word"><div><div><blockquote type="cite"><div>Am 21.07.2017 um 07:33 schrieb Ankit Aggarwal via swift-users <<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>>:</div><br class="m_-5119764626795818258m_3924764206806564691Apple-interchange-newline"><div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 20, 2017 at 10:34 PM, Geordie J via swift-users<span class="m_-5119764626795818258Apple-converted-space"> </span><span><<a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a>></span><span class="m_-5119764626795818258Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">Hi all,<div><br></div><div>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.</div><div><br></div><div>What I’d love to be able to do is to just run `git add submodule<span class="m_-5119764626795818258Apple-converted-space"> </span><a href="http://blah.com/mysubmodule.git%60" target="_blank">http://blah.com/mysubmodule.git`</a> in the Packages subdirectory and SwiftPM would just let me manage dependencies from there myself.</div><div><br></div><div>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 <i>still</i> 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><b>tldr;</b> *Please* let us manage dependencies ourselves. It’d be so easy if Package.swift had an option along the lines of <b>.Package.local(named: "XYZ")</b> 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.</div><div><br></div><div>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.</div></div></blockquote><div><br></div><div>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:</div><div><br></div><div>$ swift package edit <PackageName> --path ../path/to/self/managed/checkout/of/the/package</div></div></div></div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><div>Yes, this is what I tried this week. I’m pretty sure this is not a case of misunderstanding the feature or the docs.</div></div></div></div><div style="word-wrap:break-word"><div><div><br><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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).</div></div></div></div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div></div></div></div><div style="word-wrap:break-word"><div><div><br><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div>Sharing this setup is not automatic, but simple. Each user just needs to run the above command once per dependency.</div></div></div></div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><div>We have about 10 dependencies,<span class="m_-5119764626795818258Apple-converted-space"> </span><i>all<span class="m_-5119764626795818258Apple-converted-space"> </span></i>of which will<i><span class="m_-5119764626795818258Apple-converted-space"> </span>always</i> 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.</div></div></div></div><div style="word-wrap:break-word"><div><div><br><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div>Also, you only need to do this if you're actively working on a dependency.</div></div></div></div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><div>The point is that we will<span class="m_-5119764626795818258Apple-converted-space"> </span><i>always</i> 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).</div></div></div></div><div style="word-wrap:break-word"><div><div><br><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div>The new manifest also supports using branch instead of version range, which is very helpful during the development period.</div></div></div></div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><div>This has much the same result as top-of-tree development, but it is how we were able to "hack" SwiftPM 3 into leaving us alone.</div></div></div></div><div style="word-wrap:break-word"><div><div><div><br></div><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div>Let me know if something is unclear or if you have more questions!</div></div></div></div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><div>Maybe an overview of our structure would be helpful to make our use case clearer:</div><div><br></div><div>Main Project (git repo, not a Swift Package, contains no swift code directly)</div><div>–– Dependencies (external)</div><div>–– Subproject (<b>internal</b><span class="m_-5119764626795818258Apple-converted-space"> </span>git submodule, is a Swift Package, has multiple Swift Targets)</div><div>–––– Dependency A (<b>internal</b>, git submodule)</div><div>–––––––– Huge external C-language dependencies (managed via git submodules)</div><div>–––– Dependency B (<b>internal</b>, git submodule)</div><div><div>–––––––– Depends on internal dependency D</div></div><div>–––– Dependency C (<b>internal</b>, git submodule)</div><div><div>–––––––– Depends on<span class="m_-5119764626795818258Apple-converted-space"> </span><b>internal</b><span class="m_-5119764626795818258Apple-converted-space"> </span>dependency A</div><div>–––––––– Depends on<span class="m_-5119764626795818258Apple-converted-space"> </span><b>internal</b><span class="m_-5119764626795818258Apple-converted-space"> </span>dependency B</div><div>–––––––– etc.</div></div><div>–––– Dependency D (<b>internal</b>, git submodule)</div><div></div></div></div></div></blockquote><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Reading over this entire thread, I've come across this again, which I think sums up the pain point better than anything else:</div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><br></div><div><b>I think the friction is coming from the fact that we’d like to use SwiftPM<span class="m_-5119764626795818258Apple-converted-space"> </span><i>just to build</i>, rather than to manage our dependencies.</b></div></div></div></div></blockquote><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="auto">When I say "swift build", I expect swift to build! Not to check for commits and tags and dependencies, not to clone anything, just build what is there. For all the other stuff we have the "swift package ..." commands.</div><div dir="auto"><br></div><div dir="auto">Imagine if "swift package update" did the step that currently happens before "swift build" builds the project (dep management, cloning etc). And to retain old behaviour we could have "swift build --update-deps" with a note on failing "swift build" builds suggesting users try the update flag to get the old behaviour.</div></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><div><br>One of the core functionality of the package manager is managing dependencies. The "swift build" command doesn't do any dependency related operation unless it needs to. If there are no dependencies cloned yet, it doesn't make sense for "swift build" to error out and say run "swift package resolve" because it can already run that command if needed.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="auto">I think this would be an equally welcome addition for users not currently on a strong internet connection.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>If you already have all the dependencies cloned, the "swift build" command will never try to connect to internet.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Assuming multipackage repos are accepted this will be true for all important cases, I agree.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>We're also considering an offline mode for the "package resolve" command but that is for different reasons.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="auto"><br></div><div dir="auto">The question would be how Swift knows which dependency is which. The answer should be pretty simple: look in each Packages/package/Package.swift for the available package names and build them if there's a dependency on them somewhere in the graph.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>That sounds like a very fragile implementation. The package authors shouldn't need to care how their dependencies are being handled by the package manager, unless of course it is being edited.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="auto">There's something about that idea that seems at odds with the current git-centric model, though I'm still skeptical that the git-centric model is a reasonable base case. For example, it's confusing because Sources/TargetName uses a filesystem convention while package dependencies currently do not, but kind of actually do after "swift package edit" has been run, and would have to with any of the current proposals. Is the complexity of using git as the base case becoming clear? No matter what we're doing, the reality is that we end up with files in our filesystem. To me having the dep as a remote git repo is actually the edge case, which is the opposite of the current model.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Note that the convention system for targets is greatly simplified in Swift 4 and fully customizable.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">I did notice yesterday that tools version 4.0 allows many different target structures. I guess this is nice but having a "convention" that could be one of many things (different locations for target sources) also makes SwiftPM more complex than simple in my opinion.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>I don't think target and package dependencies are similar enough to relate them to the convention system. The package manager is fully responsible for managing the dependencies. The dependencies need to come from somewhere, which is the git url currently. The multipackage repository will allow having the dependencies in the same repository, I think this is what really fits your usecase. Unfortunately, we couldn't finish design for this feature in enough timeframe for Swift 4.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">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?</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="auto">To do anything with a moderate level of complexity took me weeks to get figure out the ins and outs of and get to a point where it was repeatable within the team. Again, I think this can be done better. And I think assuming that dependencies are local unless specified otherwise would make this a lot easier. Why not for example just have "swift package update" check out the git repos into its internal build cache and symlink them into Packages/PackageName, always building packages from ./Packages? I'd find that a lot more consistent and transparent.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Again, the package authors shouldn't need to worry about how the dependencies are being managed. The editable packages <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md" target="_blank">proposal</a> briefly explains the motivation behind making the dependencies an implementation detail.</div><div><br></div><div></div><blockquote type="cite"><div>We have discussed whether or not hiding the sources for non-editable packages is the right default. The motivation for hiding the sources is that in a large, mature, stable ecosystem there are likely to be a large number of packages involved in any particular project build, and many of those are likely to be uninteresting to the package developer. In particular, while a project developer might be interested in the source of their direct dependencies, the sources of that packages own dependencies is an "implementation detail" from the perspective of the project developer.</div></blockquote></div></div></blockquote><div dir="auto"><br></div><div dir="auto">Being interested in the source of my direct dependencies is exactly the current case. I can see the point about having many indirect package dependencies, but this is what I'm used to from other ecosystems and to be honest it has never bothered me there. More often I have found it convenient to track down bugs in 3rd party libraries etc. but I agree this would still be possible with the checkouts in .build</div><div dir="auto"><br></div><div dir="auto">Have a great weekend,</div><div dir="auto">Geordie</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div></div></blockquote><div><br></div><div>The package update command does actually need to fetch the latest tags from internet to do the dependency resolution. It may be possible to resolve the dependencies with the tags we have in cache but that may not be ideal. However, this is still useful in case there is no internet connection, so we plan to introduce an offline mode to handle those cases.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="auto"><br></div><div dir="auto">In the meantime the multi-package repo proposal seems like a step in the right direction. In a way though it seems to me like a crutch for an underlying inconsistency in both tooling namespaces ("swift build" vs "swift package") and in convention vs configuration (specific directory structure vs automated dep management via git).</div><div dir="auto"><br></div><div dir="auto">I'm not sure what the implications of this are, but I'm starting to wonder whether "swift build" and "swift package" are conceptually two different but related projects, and whether it'd be a good idea in the medium-long term to more clearly separate them.</div></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>I think I tried to explain the reason why "swift build" can run git commands above.</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="auto">Cheers,</div><div dir="auto">Geordie</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">PS. The top-of-tree workaround does work after all, but is complicated because we're also running "swift build" from within a docker image to build for other platforms, so the absolute paths are (inescapably) different between the environments.</div><div dir="auto"><br></div><div dir="auto">Again, the idea of having absolute paths there at all seems unnecessary, but until multi-package repos are available it seems the best option will be scripting a find-and-replace in ".build/dependencies-state.json" before running "swift build"...</div></div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>One solution could be using a different build folder when using docker.</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Possible, true, I didn't think of that. It'd mean even more git checkout deadweight of huge dependencies though. And the script to put the Packages in editable mode would then have to be maintained for multiple environments. The easier option is just altering the absolute paths for now.</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div><br></div><div>---</div><div><br></div><div>Lets see what others think about reconsidering local dependencies feature as that can probably help many such usecases until multi-package repository feature arrives.</div><br><blockquote type="cite"><div><div dir="auto" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div></div></blockquote></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><b></b></div><div><br></div><div>Again, this could be solved with a simple API addition in the manifest:</div><div><br></div><div>Package(</div><div> <span class="m_-5119764626795818258Apple-converted-space"> </span>…</div><div> <span class="m_-5119764626795818258Apple-converted-space"> </span>dependencies: [</div><div> <span class="m_-5119764626795818258Apple-converted-space"> </span>.package.local(named: "Dependency A")</div><div> <span class="m_-5119764626795818258Apple-converted-space"> </span>.package.local(named: "Dependency B")</div><div> <span class="m_-5119764626795818258Apple-converted-space"> </span>...</div><div> <span class="m_-5119764626795818258Apple-converted-space"> </span>]</div><div>)</div><div><br></div><div><br></div></div></div></div></blockquote></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>At the end of the day it seems we can work around this by cloning the submodules at<span class="m_-5119764626795818258Apple-converted-space"> </span><b>Project/Submodule</b>instead of<span class="m_-5119764626795818258Apple-converted-space"> </span><b>Project/Package/Submodule</b><span class="m_-5119764626795818258Apple-converted-space"> </span>and then running<span class="m_-5119764626795818258Apple-converted-space"> </span><b>swift package edit Submodule —path ./Submodule</b>, just that this process would have to be manual for each new dev cloning the repo. And then we’d still have two checkouts of the same thing. Yes, this works, it just seems very inefficient and still hacky. And it’s very possible it'll break again with future SwiftPM versions.</div></div></div></div></blockquote></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><br></div><div>I’m just surprised the idea of a "local dependency" is not seen as a first class citizen in SwiftPM, still trying to understand the logic behind that. Maybe you can give me an idea of the reasoning behind this?</div><div><br></div><div>Best Regards,</div><div>Geordie</div></div></div></div></blockquote></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><div></div></div></div></div><div style="word-wrap:break-word"><div><div><br><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>Best Regards,</div><div>Geordie</div><div><br></div><div><br></div><div>PS. In SwiftPM 3 we had been using a hack that worked great: by filling in the dependencies' "basedOn" key in `workspace-state.json`, SwiftPM just left us alone.. We were able to commit `workspace-state.json` into our base project’s git repo and the rest Just Worked™. Now with the absolute paths being checked for this doesn’t seem to be an option.</div></div><br></blockquote><div><br></div><div>Please do not rely on internals of the package manager as they're not stable and will change without notice.</div></div></div></div></div></blockquote><div><br></div></div></div></div><div style="word-wrap:break-word"><div><div><div>This was not our preferred way of going about it of course. But it was (unfortunately) the best solution to the problem.</div></div></div></div><div style="word-wrap:break-word"><div><div><br><blockquote type="cite"><div><div><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">_______________________________________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a><br><br></blockquote></div><br></div></div>_______________________________________________<br>swift-users mailing list<br><a href="mailto:swift-users@swift.org" target="_blank">swift-users@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-users" target="_blank">https://lists.swift.org/mailman/listinfo/swift-users</a></div></blockquote></div></div></div></blockquote></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div></div></blockquote></div><br><div>
<div style="word-wrap:break-word"><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>--<br>Ankit</div></div>
</div>
<br></div></blockquote></div></div>