However, I think we should still discuss if we want to support Linux/Windows from the beginning or defer that to a later point. I took the overview Since this seems quite solid. I updated the section which platform are supported in what format. We should discuss wether we want that flag in the manifest or a config file and how to name it. However, I added an opt-out mechanism as suggested to allow package creators to disallow any transitive binary dependency. I removed the allows binary flag from the proposal since the discussion showcased that it is not a real security benefit to have it. To summarise what changed: Allows binary flag removed I already pushed the changes to git, but I can't figure out how I can edit my post here. I finally found time to update the proposal a bit with things that were discussed here. Increasing the visibility of binary packages being used is still a worthwhile problem to solve, but it can be tackled as a workflow feature by tools built on top off libSwiftPM and doesn't have to be part of this proposal.There might also be a case to be made to make developers opt-in to binary packages once instead. It warrants further discussion to figure out whether this is better suited to manifest API or a separate configuration option. Because of this, it would make sense to offer package authors a way to opt-out of binary packages wholesale in order to not add a transitive dependency on one accidentally. any binary dependencies is still significant, for example it will be harder to port the package to a new platform if there are any binary dependencies. The difference between having zero vs.This makes a per binary packages opt-in during development time less important It is true that strictly speaking there is no difference between binary and source dependencies in terms of trust, as some folks on this thread also commented.And me discussed the opt-in part of this proposal and came to the following observations:
0 Comments
Leave a Reply. |