>> 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 seems pretty similar to standard overrides as part of the lockfile
proposal to me, so we could add it on there, maybe with
a convenience command line.
>> 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?
Root package always has override precedence.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
