-
Notifications
You must be signed in to change notification settings - Fork 1.4k
improve and relax the validation of explicit dependency names #3687
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
motivation: follow up work to relaxing the requirement to set an explicit name on dependency, this relaxes the requirement that such name (if/when set) must match the manifest's name attribute, which we want to deprecate over time changes: * change the validation flow to ignore the name set in the manifest, instead manage an in-memory list of names used for target based pacakge lookup which suffices * remove a few tests that are no longer needed given the relaxed requirment * fix a couple of tests that were always wrong but previous validation did not catch
@swift-ci please smoke test |
1 similar comment
@swift-ci please smoke test |
|
@swift-ci please smoke test linux |
Just wondering, is the goal to use the last path component of the package's url as the package name everywhere? |
@rauhul the goal is to make the name attribute in the manifest have no functional consequences, or iow make sure it is used for display only. this us a multi step process, and this PR brings us one step closer with SE-0292 we are transitioning to a reality where packages have unique identities, now these are derived from the url, but in the future they will be derived from a service |
@swift-ci please smoke test linux |
@swift-ci please smoke test |
motivation: follow up work to relaxing the requirement to set an explicit name on dependency, this relaxes the requirement that such name (if/when set) must match the manifest's name attribute, which we want to deprecate over time
changes: