+ 1 > On 02 May 2017, at 00:00, Martin Waitz via swift-evolution > <swift-evolution@swift.org> wrote: > > 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. >
Absolutely. I struggle to see any value in “install” at all. “Resolve” feels much more natural. Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl - A server for websites build in Swift > — > Martin > >> Am 01.05.2017 um 00:46 schrieb Jon Shier via swift-evolution >> <swift-evolution@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@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 > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
