There are many valid ways of putting the executability to work, and even of importing
It is relatively common to query
ProcessInfo for environment variables to switch development modes. Even official packages, such as SwiftPM and SwiftSyntax do so.
It can be used to detect the difference between Xcode’s native support for packages and
generate-xcodeproj, such as here. Due to bugs in each, some things are possible in one but not the other at the moment.
Earlier versions of Xcode couldn’t handle URLs that weren’t percent encoded. At that time I used to iterate every URL at the end of the manifest to automatically encode everything for Xcode.
However, care should be taken if you are dynamically adjusting dependencies. As @lukasa said, that will make
Package.resolved utterly pointless. It will have no effect on your clients, but it may or may not matter to you for your development strategy. If you look closely at SwiftPM’s manifest, it does change its dependencies, but you’ll note that doesn’t rely
Package.resolved for anything and
.gitignores it anyway.
But it is a very bad idea to try to adjust anything outside of the package manifest. When your package is a dependency, SwiftPM will be checking it in and out in multiple locations. It will cache your manifest information and then check out the code somewhere else. If you’ve tried to write into repository files, dirty Git states will cause SwiftPM to fail completely, and
.gitignored generated files won’t travel with the checkouts. There will be nothing but chaos.