[swift-build-dev] [swift-evolution] [Draft] Package Manager Revised Dependency Resolution

[Martin Waitz]

Hello,

Many of the listed package managers are for interpreted languages.
So after fetching all dependencies, your package is completely usable. It is „installed locally“.
But Swift packages have to be compiled. You have to build them to be able to use them.
For me, ‚install' comes after compilation, not before.

Using ‚resolve‘ is thus a much better name for the proposed command.
The verb ‚install‘ should only be used when it really installs the package in some way.

— 
Martin
 
> Am 01.05.2017 um 00:46 schrieb Jon Shier via swift-evolution <swift-evolution at swift.org>:
> 
> 	`install` only sounds like it should install things in the system if that’s the only type of manager you’ve ever used. If I’ve only ever used brew, of course I’ll assume that every other thing that calls itself a package manager will operate similarly. Thankfully, people learn quickly and it’s pretty easy to tell the difference between project package managers and system package mangers. Pretty much anyone developing on Apple platforms will be familiar with brew and CocoaPods  / bundler, all of which use the `install` verb, so following those would be an easy way to gain immediate familiarity. SPM really shouldn't be too different given that it will have to interoperate on systems with these tools, so choosing your own verbs would be far more confusing than using `install`. Carthage’s use of `bootstrap` is weird outlier that is always confusing to me. Plus, using `install`, allows you to use `.installed` for the file, which I think makes more sense than `.lock` or `.resolved`.
> 	A second issue is that `resolve` doesn’t sound like it installs anything at all. It sounds like a command that would just print the resolved versions of all my dependencies but do nothing else. 
> 
> 
> 
> Jon
> 
> 
>> On Apr 30, 2017, at 12:06 AM, Rick Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Thanks for the feedback, David, and apologies for the slow reply. My biggest reservation with the word "install" is that it really sounds like it should install things into the system, or another shareable location, instead of fetching dependencies into the dependency location for a single top-level package. We might actually want to add a real "install" command that does some type of installation some day in the future, though we might also choose to forever leave that sort of thing to your system package manager. And while there is some precedence for other package managers using "install" to fetch dependencies, I think there's broader precedence for it meaning to either install things into the system, or at least create an installable "build root", with e.g. `make install`, `xcodebuild install`, `brew install`, etc.
>> 
>> I just did a quick survey of the same package managers I surveyed previously to see if they all used this term, and here's what I found:
>> 
>> yarn: `install`
>> composer: `install`
>> cargo: No true equivalent, just supprts `update` or `build`. Also, uses `install` to mean something different – `cargo install` installs binary packages only, to a installation root.
>> bundler: `install`
>> cocoapods: `install`
>> glide: `install`
>> pub: `get`
>> mix: `deps.get`
>> rebar3: `get-deps`
>> carton: `install`
>> carthage: `bootstrap`
>> pip: Uses `install`, but since pip doesn't enforce the top-level-package seperation of SwiftPM, Pip's use of `install` is actually more accurate.
>> npm: `install`
>> meteor: no true equivalent, just supports `update` or `build`
>> 
>> Given that this isn't a universal term, I think I'm comfortable going against the flow a little bit if it means that we get to have clear and accurate command-line verbs. But I think this is worth adding to the "Alternatives Considered" section before we put this up for review!
>> 
>> 	- Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20170502/43de71e9/attachment.html>