-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Add swift package-registry command
#3647
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
|
@tomerd I started to implement
Right now, the How do you think we should proceed? I can think of a few possibilities:
I suspect we don't really want to get in the business of What do you think? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
| // MARK: - | ||
|
|
||
| private extension Decodable { | ||
| static func readFromJSONFile(in fileSystem: FileSystem, at path: AbsolutePath) throws -> Self { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we typically prefer to put the visibility modifier on the method and not the extension, i.e.
extension Decodable {
private static func readFromJSON ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally like ACL on private and fileprivate extensions, as it prevents helper APIs from leaking out to internal. But I'm happy to make this change if you feel strongly about it.
The only hitch is that the current .swiftformat configuration falls back to the default extensionAccessControl rule behavior of putting ACL on extensions rather than declarations. If we're still using this tool, should we update that to match project conventions?
|
|
||
| import Commands | ||
|
|
||
| SwiftPackageRegistryTool.main() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should probably transition to @main at this point.
@abertelrud @neonichu wdyt about a PR to move SwiftPM to tools version 5.5 and make use of some of the new capabilities?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking great. added a couple of ideas about the configuration, happy to help with doing that in a separate PR if it helps.
I agree and think option 2 is sufficient at this point |
|
@swift-ci Please smoke test |
|
@tomerd Aside from the unresolved feedback threads and Re: |
Add RegistryConfiguration and RegistryConfigurationTests
Co-authored-by: Yim Lee <yim_lee@apple.com>
Co-authored-by: Yim Lee <yim_lee@apple.com>
Co-authored-by: Yim Lee <yim_lee@apple.com>
Co-authored-by: Yim Lee <yim_lee@apple.com>
05481e2 to
d76923f
Compare
|
@swift-ci Please smoke test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good. some leftovers that can be removed, I suspect, but looking great otherwise.
Fix logic for location registries configuration
c7820d9 to
6aa9be2
Compare
|
@swift-ci Please smoke test |
|
@swift-ci smoke test |
|
@tomerd Sounds good. Yes, this is all ready to be merged once CI is passing. |
This PR implements the
swift package-registrycommand with itssetandunsetsubcommands as described in "Registry configuration subcommands"Motivation:
Implement SE-0292.
Modifications:
PackageRegistrylibrary and test target containingRegistryConfigurationtype in thePackageRegistrymoduleswift-package-registryexecutable targetImplement(see Add.netrcsupportswift package-registrycommand #3647 (comment))Result:
With this change, Swift Package Manager will be able to read and write registry configuration files.