It seems the that none of the swift package commands return whether a package dependency is in edit mode ie swift package edit has been called on it. The only way to find out this out is to check for the existence of a folder or symbolic link inside the Packages folder. Is this the case?
hi @adam-fowler, not sure if this helps, but this is a feature we plan to deprecate in the coming future: mark edit/unedit functionality as deprecated by tomerd · Pull Request #3718 · apple/swift-package-manager · GitHub and replace it with a more explicit "override" feature that can be used across IDEs and the CLI. what is the use case in which this is needed?
I was hoping to add local editing of packages into the Visual Studio Extension and this is currently the only method I can see of doing it. I had a look at the PR you link to and it seems the suggestion for implementing local overrides is to edit the Package.swift file. This seems like a step backwards.
1 Like
I have to say I've been enjoying the edit command quite a bit. It is great when you find an issue in a project related to some dependency and you can quickly start editing that dependency at exactly the correct version and just rebuilt and see if this fixes the problem. It significantly reduces the effort to provide bugfixes for dependencies and to debug problems. I would vote for keeping it/embracing it!
2 Likes
It sounds like the plan is to replace with it a more powerful feature, which is also fine.
I haven’t had to use it often, thankfully, but when I have it’s proven invaluable. It also makes it fairly easy to determine whether forking something is worthwhile, whether temporarily or permanently.
Absolutely, if the new thing is more powerful, great. I just wanted to second @adam-fowler's comment that a step backward would be a pity. The ease of use of swift package edit is great.
@tomerd if the edit/unedit commands become deprecated what's the recommended way to achieve this then? Editing the manifest seems dangerous especially if you're editing a transitive dependency that is pulled in by your dependencies
@tomerd Do you have any more details on the explicit "override" feature? Is there work already being done?
hi folks,
the design of the "override" feature is wip and once a bit more mature will be shared with the community as part of a typical evolution process. rest assured we would not deprecate edit/unedit until an adequate replacement is in place. the point in my reply to @adam-fowler's original question was that it may not be worth investing heavily in supporting this feature (presumably for the vscode plugin?) if it will be changed in the near-ish future.
very high level design thoughts (cc @NeoNacho)
atm "edit mode" is actually two different features: you can trigger it from the CLI (which is what the OP is asking about) in which case it is managed as an internal state in SwiftPM, while Xcode has a different way of achieving "edit mode" documented in Apple Developer Documentation, which is not always reliable given reliance on weak identity derived from the path and the manifest name which cannot be 100% unique.
to unify these into a single reliable feature, we have been considering an explicit override file (somewhat similar to the mirrors file, and potentially superseding it) where you can point a package by its unique identity to a location on disk where its being edited, e.g.:
{
"swift-nio": {
type: "fileSystem",
path: "/Users/tomerd/code/swift/swift-nio"
}
}
this means you do not need to make changes to the manifest file in order to edit the package locally and you can easily switch from edit/non-edit mode. we can of course also add sugar in the shape of edit/unedit commands from the CLI but they may behave a bit differently from the ones we have today.
this can also allow users to do other types of overrides, such as what is possible today in mirrors:
{
"swift-nio": {
type: "sourceControl",
url: "http://github.com/tomerd/my-swift-nio-fork"
}
}
and once registry support is in place, do the same for remapping identities in enterprise registries:
{
"swift-nio": {
type: "registry",
identity: "swift-nio-internal-testing"
}
}
as mentioned above these are preliminary thoughts, and once a bit more mature will be shared with the community as part of a typical evolution process. rest assured we would not deprecate edit/unedit until an adequate replacement is in place.
7 Likes