❄️ A developer friendly package manager for Swift; 100% compatible with Swift Package Manager
The official Swift Package Manager is great at actually managing packages (resolving package versions, compiling source, etc.), but it lacks in developer friendliness. Ice uses Swift Package Manager in its core, but provides a much more developer friendly layer on top of SPM.
A few features Ice has that SPM lacks:
- Beautiful, yet information dense output (particularly while building and testing)
- Ability to imperatively manage
Package.swift
(e.g.ice add RxSwift
) - A centralized registry of packages
- Automatic rebuilding / restarting of an app upon source changes
- Short command names for the most used commands
Mint (recommended)
mint install jakeheis/Ice
git clone https://github.com/jakeheis/Ice
cd Ice
swift build -c release
install .build/release/ice /usr/local/bin
Manage dependencies:
ice add RxSwift
ice add Alamofire 4.5.1
ice add jakeheis/SwiftCLI
ice remove Alamofire
Manage targets:
ice target add Core
ice target add --test CoreTests --dependencies Core
ice target remove CoreTests
Manage products:
ice product add CoreLib --static
ice product add cli --exec --targets=CoreLib
ice product remove CoreLib
The built in registry (https://github.com/jakeheis/IceRegistry) consists of the most-starred Swift repositories on Github. You get these for free, but you can also add your own personal entries to a local registry:
> ice registry lookup Alamofire
https://github.com/Alamofire/Alamofire
> ice registry add https://github.com/jakeheis/SwiftCLI SwiftCLI
> ice registry lookup SwiftCLI
https://github.com/jakeheis/SwiftCLI
Once packages are in the registry (either the shared registry or your local registry), you can refer to them just by the project name:
> ice add Alamofire
> ice add SwiftCLI
ice build
and ice run
both accept a watch flag which instructs them to rebuild/restart your app whenever a source file changes:
> ice build -w
[ice] rebuilding due to changes...
Compile CLI (20 sources)
● Error: use of unresolved identifier 'dsf'
dsf
^^^
at Sources/CLI/Target.swift:74
[ice] rebuilding due to changes...
Compile CLI (20 sources)
Link ./.build/x86_64-apple-macosx10.10/debug/ice
> ice run -w
[ice] restarting due to changes...
Check if any dependencies are outdated
> ice outdated
+-----------------+-----------------+----------+--------+
| Name | Wanted | Resolved | Latest |
+-----------------+-----------------+----------+--------+
| FileKit | 4.1.0 ..< 5.0.0 | 4.1.1 | 4.1.1 |
| Rainbow | 3.1.1 ..< 4.0.0 | 3.1.1 | 3.1.1 |
| Regex | 1.1.0 ..< 2.0.0 | 1.1.0 | 1.1.0 |
| SwiftCLI | 4.0.0 ..< 5.0.0 | 4.0.3 | 4.0.4 |
| SwiftyTextTable | 0.8.0 ..< 1.0.0 | 0.8.0 | 0.8.0 |
+-----------------+-----------------+----------+--------+
Update the current package's dependencies
> ice update
Update https://github.com/jakeheis/SwiftCLI
Resolve https://github.com/jakeheis/SwiftCLI at 4.0.4
> ice update SwiftCLI 5.0.0
Clean the current project by removing build artifacts
Remove everything in the .build
folder (build artifacts, checked out dependencies, etc.)
Initialize a new package in the current directory
Dump the current package as JSON
Describe the package in the registry with the name "Alamofire"
Search for packages in the registry with "CLI" in their name or description
Generate an Xcode project for the current project and open it
Configure Ice behavior. Recognized keys:
- reformat: when writing
Package.swift
, should Ice reformat the file to be alphabetized
Yes! Because Ice is built on SPM, you can seamlessly go back and forth between ice
and swift
commands.
Why does Ice internally use Swift Package Manager at all? Why not write an entirely new package manager?
A goal of Ice is to retain 100% compatibilty with SPM -- Ice should not splinter the ecosystem in any way. By building Ice on top of SPM, we can easily attain that goal.
Why not contribute these improvements directly to SPM rather than creating a new layer on top of it?
Swift Package Manager has considered some of the improvements offered in Ice but rejected them (for now). Notably, SPM chose to keep the package manager within the swift
executable, meaning that commands are often quite verbose. I believe that tasks as common as cleaning a package should not require the user to type commands as lengthy as swift package clean
.
Having said that, it's my hope that Ice can be a proving ground for some of these features, a place where they can be fine-tuned and eventually can make their way into SPM core. Ideally, Ice will one day be unnecessary.