On Wed, Mar 30, 2016 at 1:01 AM, Max Howell <[email protected]> wrote:
> 1) You have to remember to modify it back at some point, and if you are >> iterating frequently this is tedious and error-prone >> > > One way I can think of to avoid Package.swift is to place DevPackages > inside some special folder (perhaps: DevPackages/) inside the root package > which sounds good if I am developing some patch to some package but it > might be awkward if I am starting to write a library and want to create a > package to try it because I'll already have created the library package > (though maybe minimal) but then I'll have to move the library inside > DevPackages/ > > > Well, it seems to me part of the utility here is having a package be a > local clone in an entirely different directory. So this sounds a bit > tedious. > > Any other way you can think of to avoid Package.swift? > This would be a bit awkward but sounds good enough to me > > >> 2) We don’t want any chance that DevPackage gets into the package graph >> and thus the ecosystem. >> > > what if one of the dependencies depend on a package inside DevPackage then > should the DevPackage be preferred? > > > Don’t understand. > RootPackage Dependency: APackage DevPackage: BPackage APackage Dependency: BPackage If DevPackages don't specify version in Package.swift, in case of a collision should the DevPackage be always preferred? -- Ankit
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
