> 2. I like VersionLocks.json well enough, but would like to see a discussion > about possible alternatives. My personal proposal (in line with #1) is to use > "PackageVersions.json" which has a nice agreement with Package.swift and > would mean two common metadata files show up adjacent. I don't really want to > bike shed on the name, but I suspect whatever we pick first will last for a > while so I would at least like to review the various alternatives. I also > will throw out that my personal opinion is we don't need to pick a name that > bears much resemblance with existing terminology, whatever we pick will > eventually become "the standard" for the SwiftPM ecosystem so I would prefer > to pick the most-descriptive-possible name up front, not one that alludes to > the same concept in other systems.
I like PackageVersions.json > > 3. I like the terminology section here, I almost feel like we should adopt > that as official terminology in our documentation (which I don't think we > have yet, correct me if I am wrong). We don’t, but I agree, we should aim to pick some names and use them consistently. > 4. I would like it if the lock file recorded the exact SHA it received, and > validate that when retrieving. This helps protect users against MITM attacks > or unexpected changes if an upstream modifies a tag. It also can be used as > part of safety checks when migrating to an alternate repository host which is > expected to have the same content. Good point, this should be there. > 5. The "workflow - build" sections #2,3,4 are rather complicated. Is this > because the proposal is trying to work with existing Packages layouts, or > because the proposal is trying to handle the various variations of what the > user may have checked in inside the Packages subdirectory? The latter, if we are to support checking in the `Packages` directory, we should handle it when it is so. Is there a simpler way you can see? > 6. I wonder if we should be defining, as Eloy alludes to, two different > things: > - The version lock file, which defines the expected versions for the package > manager to use when it is doing package resolution. > - The package state file (in Packages.swift), which is used by the package > manager to track information on the Packages/ subdir state in order to > provide useful features primarily focused at the scenarios when the user is > modifying those files. > Currently it seems like a lot of the behaviors in the proposal are focused at > the latter case, but they feel like they should be decoupled problems to me. I’m not sure we need a second file, since the versions of the “installed dependencies” are recorded in the directory names as well as that we also do full clones, so that information is part of the clone & checkout.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
