carthage / carthage Goto Github PK

Originally from #8.

Since any project is going to rely upon its dependencies for a successful build. However, it should assume that the dependencies have already been checked out.

Note that this has nothing to do with subprojects, because Xcode will take care of those for us.

We should clone dependencies—and their dependencies’ dependencies—while trying to find the versions of everything that match what's specified in the config.

Where would these checkouts live? A global folder, or something inside the repository? The latter could be useful if you want to commit your dependencies (to protect against them disappearing).

After running sudo make install, I tried running carthage update in the project's root directory. I guess I've never entered my credentials for HTTPS cloning, since I was suddenly prompted to do so--once for each dependency!

$ carthage update
*** Cloning ReactiveCocoa
*** Cloning LlamaKit
*** Cloning Quick
*** Cloning xcconfigs
*** Cloning Nimble
Username for 'https://github.com': Username for 'https://github.com': Username for 'https://github.com': Username for 'https://github.com': Username for 'https://github.com':

I'm not sure if entering my username/password 5 times would have done the trick. But the following change fixed my problem:

diff --git a/CarthageKit/GitHub.swift b/CarthageKit/GitHub.swift
index 84f5714..966ee92 100644
--- a/CarthageKit/GitHub.swift
+++ b/CarthageKit/GitHub.swift
@@ -16,7 +16,7 @@ public struct Repository: Equatable {

    /// The URL string that should be used for cloning the Git repository.
    public var cloneURLString: String {
-       return "https://github.com/\(owner)/\(name).git"
+       return "[email protected]:\(owner)/\(name).git"
    }

    public init(owner: String, name: String) {

I also tried caching my username/password, but I couldn't authenticate. Maybe because I use 2-factor authentication? Not sure.

Suggestions:

• HTTPS cloning is uncool. Why not SSH? Or an option to choose (sorry if that already exists).
• It'd be nice to at least do one prompt at a time.

Discovered while testing #57. git clone --recursive doesn't do anything with bare repos, and git checkout (rightly) won't automatically update submodules.

Since the .gitmodules file is checked out to something that's not the top-level, git submodule init doesn't even work. We'll need to do something better.

Our API is super subject to change, so I'm not too fussed, but we should take a quick scan over the visibility annotations in CarthageKit and make sure that public is only applied to those APIs that make sense to export (or test).

I think anything public should meet at least one of the following criteria:

• Non-trivial or duplicative for an application to implement themselves (e.g., most things to do with Xcode integration)
• Part of the core functionality of Carthage (e.g., Cartfile parsing)
• Exercised in the test target (because Swift is unable to use internal for this)

Anyone disagree with that list?

If I put ReactiveCocoa into my Cartfile, how is it supposed to find its copy of LlamaKit to build successfully? Right now, everything is dropped at the application level, but it seems like we'll need symlinks or something into every dependency, so they can find each other.

Explain why we have a framework/application split, both for contributors (so they know which target to write code in), and for users (who may be interested in using CarthageKit on their own projects).

This command should use xcodebuild (or perhaps xctool) to build a linkable binary framework from your project.

The functionality here will eventually be part of the larger “set up my dependencies” command.

It'd be nice to inject a custom Cartfile for use by a dependency of your project—in other words, specify external Cartfiles for dependencies listed in your top-level Cartfile.

I can foresee a few uses for this:

1. Updating a project's dependencies before the maintainers are able to do so themselves, without needing to fork the project
2. Relaxing a project's dependency requirements, if they've been specified too strictly
3. Using Carthage on projects that have no awareness of it, or no desire to use it

That last point might make this a candidate for our initial release, since few—if any—projects will have Cartfiles when this repository is made public.

@Carthage/owners Any thoughts on whether this should be a prerequisite to shipping?

Now, I'm very unfamiliar with Mac development but I think a sudoless install will provide a better user experience.

The obstacle seems to be the /Library/Frameworks folder.

Can the Framework be bundled into the binary, or can it be put in ~/Library/Frameworks?

To make it easy for users to get up and running, we should offer a simple script or Makefile that can build and install Carthage to a system-wide location.

This is a huge difference between Carthage and most package managers (even those for other languages), so we should highlight it in big letters.

A very basic first pass could perhaps use GitHub repository names and specific tags/releases to match.

One thing is clear: these files should not allow arbitrary code. They should just be a configuration file format.

We need a file to track which versions we resolved for dependencies, so checking out a past commit results in consistent dependency versions everytime.

Also, what exactly are the heuristics for picking which of the many shared schemes a workspace might have?

As of #69, attempting to check out a project with submodules twice (doing nothing else in-between) will fail the second time, with an error about submodule folders not being empty.

Whatever our solution, we should try very hard not to lose work.

Either we need to rebuild things, or we need to ensure that Xcode rebuilds things. The latter is going to be a better experience for the user I think.

Originally from #8.

The intention is that a Carthage user should be able to drag-and-drop a framework built by Carthage into their project/workspace, and have it Just Work™ going forward—even when building for a different platform, or if the dependency version changes, or when a different build configuration is chosen.

This might mean using Xcode's BUILT_PRODUCTS_DIR, but that worries me because it can get deleted frequently, and doesn't let users commit binaries to source control (if desired).

It might be easier to use a common, top-level subfolder of the application's repository. Users who don't want to commit the binaries can ignore this folder. However, this might require adding some search paths to their project settings.

A user would configure their project to include Carthage.xcconfig; they’d carthage build; and then everything would be glorious?

Most of our commands default to the working directory of carthage, but we should always allow an arbitrary directory path to be passed in.

In the README, we should explain what Carthage requires to successfully build a framework (hopefully not much), and explain how to help projects get into this state if they aren't already.

It could be useful to clear the ~/carthage/dependencies directory so that everything is re-cloned when you next run carthage checkout.

We should support cloning and building arbitrary tags to start with, but maybe there's something we can do specifically with capital-R Releases that would be interesting.

For example, if a release has detailed notes, maybe we could present those somehow. Or if it has binaries attached, maybe we can use those instead of building our own from scratch (extra important given that every Xcode update breaks something).

Apparently Xcode can't figure out that it can locate modules in Carthage.build/{Mac,iOS}, even if you drag a framework from the folder into the parent project.

That means the current installation steps look like:

1. carthage {bootstrap,update,build} on the command line.
2. For a framework ReactiveCocoa, drag platform-specific ReactiveCocoa.frameworks into the project, or add -framework ReactiveCocoa to the linker flags.
3. Add Carthage.build/Mac to the Framework Search Paths for any OS X target(s), and Carthage.build/iOS to the Framework Search Paths for any iOS target(s). Sharing the path between both targets fails spectacularly.

I'd love to make that final step unnecessary, or at least use some Xcode build setting that lets the user add just one Framework Search Path—something like Carthage.build/$(SDKROOT), but not as fragile.

Since Carthage has to create bare clones Git repositories of all your dependencies anyways, it could also git submodule add each repository into your local project folder—but use a local clone path instead of a remote URL. This would allow you to use Carthage as usual, but still have versioned submodules (if you're into it).

We could even make this clever and write the remote URL into .gitmodules, but use the local URL for cloning and updating the submodule in the particular user's working directory. This would allow you to set up a project with Carthage, but consume it with plain Git machinery.

JSON was easy to get up and running, but a simple text file in the vein of Cabal would be nice.

Useful for automation, or third-party tools that want to extend our functionality.

This package should install carthage into /usr/local/bin and CarthageKit.framework into /Library/Frameworks.

In other words, sudo make install, but as a nice binary.

If I want a dependency to be present at a specific path that differs from the default Carthage.checkout folder, I should be able to specify that in the Cartfile.

Carthage should notify you (politely) that a new version is available and perhaps even offer to open the URL to the newest release.

Auto updating will depend on this; notifications are a start.

Everything should be redirectable if we want CarthageKit to be useful in other applications.

Scrub the codebase for uses of RACError.Empty or failure() without an argument, and replace them with real, informative errors.

How would I specify a local git repository as an origin?

It's super noisy right now because we basically pass through xcodebuild output unimpeded. Maybe we should instead route all of that to a file, only show progress (e.g., Building scheme “ReactiveCocoa Mac” for OS X), and then inject errors if they occur.

Originally from #8.

So, e.g., carthage build -configuration Debug would give you debug versions of all dependencies.

Eventually, we could do something more automatic, but this would be an easy first step to support customization.

This should:

1. Download all dependencies, recursively
2. Check out the latest version of each dependency that will satisfy all version requirements—or bail out, if the requirements conflict (#7)
3. Write the resolved dependency version information to Cartfile.lock
4. Build all dependencies (#38)
5. Put all built frameworks into a known location that the application project can link to (#39)

After the interrupt, if I wait a while more stuff shows up on my terminal. Bit weird. Like child processes aren't also being killed immediately and they're still rolling.

• Reach out to CocoaPods folks ahead of time
• Tease about Carthage on Twitter, prior to opening it up
• Publish GitHub release, along with a pkg installer
• Change repo tagline
• Dark ship the org (make everything public, with no announcement)
• Actually, officially announce everything

This command is really meant to be used to build a project's dependencies, so it doesn't make much sense for it to build the project in WD.

Maybe this behavior could be enabled with a command-line flag, though. That could be useful for testing that your project builds successfully with Carthage.

This should probably go in the “preparing your framework” section.

Right now, only GitHub.com is supported. This would expand support to GitHub Enterprise and other servers.

If a user modifies something in the folder of one of their dependencies, would git checkout --force lose their changes? If so, we should use something safer.

Including writing a Cartfile, and adding the built frameworks to the Xcode project.

Imagine this dependency structure:

1. Mac Application depends upon…
2. OctoKit Mac depends upon…
3. ReactiveCocoa Mac

How do we know which ReactiveCocoa scheme to build when a command like carthage build is executed?

We could maybe figure it out by trying to align the architectures of each project, but that seems like a pretty hairy yak, and error-prone.

For iOS, we also need to consider the fact that iPhoneOS and iPhoneSimulator are two different platforms, and frameworks will accordingly need to be built for both.

It seems like the simplest solution might be to build all schemes of a project, then place the built frameworks into platform-specific directories. If we can use some magic Xcode configuration variable to find the right folders, and frameworks therein, maybe everything will Just Work™?

This should:

1. Download all dependencies, recursively
2. Check out the locked version of each dependency
3. Build all dependencies (#38)
4. Put all built frameworks into a known location that the application project can link to (#39)

If a Cartfile.lock does not yet exist when this command is run, it should be equivalent to carthage update instead (and probably spit out a warning).

carthage help should list commands, carthage help build should list flags for that command, etc.

Write and submit a formula to Homebrew, for even easier installation.

Depends on #18.

Defaulting to ~/.carthage/dependencies is reasonable, but let's allow that to be overridden. (Through user defaults, maybe?)

Each tool is appropriate for certain things. Let's include an accurate (not mudslinging) description of what those are in the README, so users can make an informed decision.

Ideally dynamic frameworks (though these are iOS 8+).

I haven't checked whether roll-your-own static frameworks are supported, but I don't see why they'd have any trouble. Still, it might be easier to advise framework authors to just create dynamic framework targets.