Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Skip schemes #1227

Open
mstfy opened this Issue Mar 30, 2016 · 70 comments

Comments

Projects
None yet
@mstfy
Copy link

mstfy commented Mar 30, 2016

When I build RxSwift with carthage it builds RxSwift, RxCocoa, RxBlocking and RxTests. Is there a way to tell carthage to build only RxSwift and RxCocoa and skip other schemes?

@mdiep mdiep added the question label Mar 30, 2016

@mdiep

This comment has been minimized.

Copy link
Member

mdiep commented Mar 30, 2016

No, there's not. ☺️

@robertjpayne

This comment has been minimized.

Copy link

robertjpayne commented Apr 19, 2016

@mstfy I have a similar need and I've simply scripted Carthage via a Rakefile and the subprocess gem. Luckily schemes are located inside *.xcodeproj/xcshareddata/xcschemes/**and are pretty easy to find and remove.

@jeeftor

This comment has been minimized.

Copy link
Contributor

jeeftor commented Apr 30, 2016

so you do a carthage update --no-build -- delete schemes followed by a ``carthage build` ?

@Antondomashnev

This comment has been minimized.

Copy link

Antondomashnev commented Sep 26, 2016

@robertjpayne can you please elaborate on your solution, would be helpful, because I have similar problem.

@lukescott

This comment has been minimized.

Copy link

lukescott commented Nov 16, 2016

I have a similar problem with https://github.com/aws/aws-sdk-ios

They have one project file, but multiple build targets. It builds all the frameworks:

*** Building scheme "AWSDynamoDB" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSMachineLearning" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSCognitoIdentityProvider" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSAutoScaling" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSCognito" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSAPIGateway" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSSQS" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSSNS" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSKinesis" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSCloudWatch" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSSES" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSElasticLoadBalancing" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSLambda" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSIoT" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSCore" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSSimpleDB" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSEC2" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSS3" in AWSiOSSDKv2.xcodeproj
*** Building scheme "AWSMobileAnalytics" in AWSiOSSDKv2.xcodeproj

Which takes about 30 minutes or more. I just want S3.

@mdiep

This comment has been minimized.

Copy link
Member

mdiep commented Nov 17, 2016

In that case, I'd suggest using something like https://github.com/guidomb/carthage_cache or https://github.com/146BC/RomeBuild.

@Antondomashnev

This comment has been minimized.

Copy link

Antondomashnev commented Nov 17, 2016

@mdiep thanks, that's something at least. I think I'll take a look on Carthage itself and maybe it's not that hard to add scheme(s) parameter to build option. Will follow-up soon 🚀

@guidomb

This comment has been minimized.

Copy link
Contributor

guidomb commented Jan 4, 2017

@Antondomashnev Hey! I am the author of CarthageCache and I am facing the same issue. AWS takes 30 minutes, and although thanks to carthage cache we can avoid having to wait 45 mins for the entire build, every now and then we need to update AWS. Did you have the chance to take a look at adding a --scheme parameter?

@Antondomashnev

This comment has been minimized.

Copy link

Antondomashnev commented Jan 4, 2017

Hi @guidomb, I've recently implemented the first step in the Commandant and I haven't started yet with the --scheme parameter implementation. I'm also wondering about the solution proposed in #1616, maybe this is a better option but I have to read it carefully.

@Antondomashnev

This comment has been minimized.

Copy link

Antondomashnev commented Jan 23, 2017

Just a follow-up, I'm planning to propose an update to Carthage, but before I require this PR to be merged since the Commandant with my update is in Swift 3.

@fostah

This comment has been minimized.

Copy link

fostah commented Mar 10, 2017

Just a wanted to post a work-around that I implemented for AWS. It's a makefile target.

carthage-update:
    @cd $(IOS_DIR) && carthage update --no-build 
    @cd $(IOS_DIR)/Carthage/Checkouts/aws-sdk-ios/AWSiOSSDKv2.xcodeproj/xcshareddata/xcschemes && \
        find . ! -name "AWSAPIGateway.xcscheme" ! -name "AWSCore.xcscheme" ! -name "AWSIoT.xcscheme" -delete
    @cd $(IOS_DIR) && carthage build --platform iOS

I hope it helps until a more permanent solution exists.

EDIT

It's actually better to run carthage update --no-build instead of carthage checkout. The former will generate the .resolved file that's needed.

@freak4pc

This comment has been minimized.

Copy link

freak4pc commented Mar 13, 2017

Was just looking in Carthage and bumped into this, so practically we would need to install the entire AWS SDK which includes about 30-40 different sub-SDKs, just to use 3 or 4 of them? That seems excessive... Would also make an issue with CI unless the CI itself would also cache the assets (or we would commit the actual built binaries)

Are there any thoughts on how to work around this?

@mdiep

This comment has been minimized.

Copy link
Member

mdiep commented Mar 13, 2017

You can try the new --use-cache option.

Otherwise the Makefile solution shared by @fostah looks fine.

This stinks, but it's really an issue with the AWS SDK—not with Carthage.

@freak4pc

This comment has been minimized.

Copy link

freak4pc commented Mar 13, 2017

Well it is definitely an issue of AWS but that kind of granularity doesn't seem like an excessive feature perhaps? I think many of the bigger companies make SDKs this way (Google and Facebook as well). Definitely not saying that is any good but perhaps it's worth discussion of how to achieve that granularity in some way?

@dcaunt

This comment has been minimized.

Copy link
Contributor

dcaunt commented Mar 13, 2017

--cache-builds rather than --use-cache 😃

@BobElDevil

This comment has been minimized.

Copy link
Contributor

BobElDevil commented Jun 15, 2017

So I think one of the problems that keeps coming up here and the various dupes is the talk of who is doing the scheme specification:

  • The consumer of the dependency: This I agree with the historic answer of "Nope. Never gonna happen." This introduces quite a bit of complexity if you have a common dependency with different requests for schemes in two different downstream projects. There may not be a 'right' answer of what to build in cases like that. In addition, it requires digging into the resolver logic itself to figure out what to build. Since one of the main tenants of carthage is simplicity, this is really a no-go
  • The dependency author themselves: This I think makes sense. The author may have schemes that are shared for other developers, but should not be exported to consumers. By limiting it to the author themselves, then there's no resolution time calculations, it's merely an extra filter to apply at build time. Additionally if problems do arise due to 'missing' frameworks, it's a problem to be taken up and addressed by the framework author themselves, since it's a one size fits all solution, as it is today, with just an extra bit of customization.

I've run into situations myself where it would be nice to have a 'workspace that builds all carthage dependencies directly' for development of a framework, but then just having a definitive project scheme for the framework itself. Currently we get around that by getting fancy with symlinks and generated schemes, which is definitely not ideal.

@mdiep If we limited this discussion to the second bullet point (via some sort of cartfile ignore file or something), do you think that would be something we would be interested in supporting in carthage?

@mdiep

This comment has been minimized.

Copy link
Member

mdiep commented Jun 15, 2017

I do think that makes some sense. I definitely agree that this is a framework author issue; not a framework consumer one. And ignoring certain schemes definitely seems like the easiest way to do that.

Where this has been stuck in the past is in how to specify that. In the past, we've talked about a general file that can accept these sorts of things using OGDL. (You can search issues/PRs for mentions of this.) I don't know whether that actually makes sense or not.

We can consider a reasonable proposal for how to specify that. (It might be done best as a PR to the documentation.)

@Dschee

This comment has been minimized.

Copy link
Contributor

Dschee commented Jun 15, 2017

@BobElDevil @mdiep I agree with both of your points, that we could improve skipping development schemes for framework projects further. But I don't think that would solve the actual issue here. So I highly disagree with statements like "this is a framework author issue; not a framework consumer one". Let me bring up a very recent discussion as an example why: Moya/Moya#1125.

Here's a summarization of the issue with Moya from my point of view:

  • Moya is a framework with the goal of being usable both with and without reactive programming
  • Moya supports multiple reactive programming frameworks (ReactiveSwift & RxSwift)
  • Moya tries to keep contributing & maintenance as simple as possible and therefore doesn't split their project into separate repositories
  • To reach these goals, Moya has three targets ("Moya", "ReactiveMoya" and "RxMoya")
  • Each target has a different set of dependencies
  • When Moya is used as a dependency within an app project, all of these three schemes are built, including all of their sub dependencies
  • A consumer always wants only one of those targets and its dependencies
  • A consumer currently always has to wait more than three times longer than needed if he doesn't want to use reactive programming (actually even more than 10 times longer for this case!)

Moya is just a current example here, other frameworks have similar issues, but I find Moya to be a good mixed example since it both has multiple targets itself and different sub dependencies for each target.

I think any solution that would prevent all frameworks from building, which I don't want to be built as a consumer of the framework, would be a great addition to Carthage. That's what I thought this issue (and several others) was about. And I also strongly believe that a package manager should support as many project structures as possible, so long as this does not interfere with the core goals of the project.

This brings me to the point of what the core goals of Carthage actually are – this is what I observed:

  • Flexibility
  • Unintrusiveness
  • Simplicity
  • Creates no extra work for framework authors

All of these goals can also be found to be clearly stated in the README.


Now, let's see the current state of this framework regarding those goals and the inclusion of Moya:

  • Flexibility: Consumers cannot include just specific schemes/frameworks
  • Unintrusiveness: No problems here
  • Simplicity: It sure is simple
  • Creates no extra work for framework authors: Not at all, see alone the fact that Moya is discussing to split their project for supporting good Carthage build times ...

I don't know about any other suggestion, but see my suggestion on how we could solve this here. Maybe it's not the best solution, but let's see how it serves the goals:

  • Flexibility: Consumers can exclude any frameworks they like
  • Unintrusiveness: No problems here
  • Simplicity: It still is very simple, just adding a new file
  • Creates no extra work for framework authors: Moya doesn't need to be changed at all

So, to me there's no reason for Carthage not to add such a feature. Every issue I read so far was about "dependency resolution hell" (e.g. the "The consumer of the dependency" section of @BobElDevil's comment above) – but my suggestion clearly states that the new Cartfile.ignore would only be looked at within the current project (just like Cartfile.private is) and therefore no such issues should arise at all.


This is what I think. I'm really interested in your opinions. I'd be willing to tackle this feature myself but of course would only do this if there's a chance to be merged.

@mdiep

This comment has been minimized.

Copy link
Member

mdiep commented Jun 15, 2017

So I highly disagree with statements like "this is a framework author issue; not a framework consumer one".

A better statement to make would probably be: There are 2 orthogonal issues here: (1) framework authors who have schemes that should never be consumed and (2) consumers who wish to avoid extra work during building.

I'm sympathetic to (1), but feel that (2) is adequately addressed by binaries and caching.

@raid5

This comment has been minimized.

Copy link

raid5 commented Dec 20, 2017

I've been dealing with a timeout issue on BuddyBuild due to the huge AWS SDK. Similar to @fostah's approach, I created a shell script for Carthage that BuddyBuild executes which strips out schemes I do not need to build.

Here is the script: buddybuild_carthage_command.sh

@Dschee

This comment has been minimized.

Copy link
Contributor

Dschee commented Dec 22, 2017

If anybody is interested in this feature, please help me out with my PR #1990 – I'm stuck with the reactiveness of this repo ...

@Dschee

This comment has been minimized.

Copy link
Contributor

Dschee commented Apr 22, 2018

Hey guys, I just finally finished my PR #1990 with help from the amazing @petester42.

I've tested it out and it's working great, so you can taste faster build times too, once it get's merged!
Just wanted to keep you updated! 😉

@stale

This comment has been minimized.

Copy link

stale bot commented Jun 30, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Jun 30, 2018

@Dschee

This comment has been minimized.

Copy link
Contributor

Dschee commented Jun 30, 2018

Issue is still apparent with many people waiting for #1990 to be merged but @mdiep being reluctant to merge as repeated again here lately.

@stale stale bot removed the stale label Jun 30, 2018

@jdhealy

This comment has been minimized.

Copy link
Member

jdhealy commented Jun 30, 2018

Not just @mdiep — idk if ’reluctant to merge’ is the term to use, but might as well throw me in there too.

(Haven't posted in that PR as-of-yet, because @mdiep has summed up my thoughts so far, but I guess it bears repeating…)

@mdiep mdiep added enhancement and removed question labels Jun 30, 2018

@lukescott

This comment has been minimized.

Copy link

lukescott commented Sep 5, 2018

I'm not sure I like the solution presented in #1990. I would rather list the dependencies I use rather than the ones I don't want to use. Still, I would like a solution, even if it is put behind an experimental flag.

@JetForMe

This comment has been minimized.

Copy link
Contributor

JetForMe commented Sep 18, 2018

I'd love to be able to specify the schemes I want in my Cartfile. Right now, I have:

github "segmentio/analytics-ios" ~> 3.6
github "Alamofire/Alamofire" ~> 4.7.3
github "agilebits/onepassword-app-extension" "add-framework-support"

And I get:

$ carthage update
*** Fetching Alamofire
*** Fetching onepassword-app-extension
*** Fetching analytics-ios
*** Checking out onepassword-app-extension at "bcc4cc97fed9a6e73fa204f2e61138e353cb3ef7"
*** Checking out analytics-ios at "3.6.9"
*** Checking out Alamofire at "4.7.3"
*** xcodebuild output can be found in /var/folders/16/jfb809_s2fz01ql7k494f6pc0000gn/T/carthage-xcodebuild.Nl71yf.log
*** Downloading analytics-ios.framework binary at "Version 3.6.9"
*** Building scheme "Alamofire tvOS" in Alamofire.xcworkspace
*** Building scheme "Alamofire watchOS" in Alamofire.xcworkspace
*** Building scheme "Alamofire iOS" in Alamofire.xcworkspace
*** Building scheme "Alamofire macOS" in Alamofire.xcworkspace
*** Building scheme "OnePasswordExtension" in 1Password Extension Demos.xcworkspace

But I wish I could write something like this. This is akin to me specifying the version number: I need some a priori knowledge of the versions available, it's acceptable to rely on knowledge of the schemes available:

github "segmentio/analytics-ios" ~> 3.6
github "Alamofire/Alamofire" ["Alamofire IOS", "Alamofire watchOS"] ~> 4.7.3
github "agilebits/onepassword-app-extension" "add-framework-support"

and get

$ carthage update
...
*** Checking out Alamofire at "4.7.3"
*** xcodebuild output can be found in /var/folders/16/jfb809_s2fz01ql7k494f6pc0000gn/T/carthage-xcodebuild.Nl71yf.log
*** Downloading analytics-ios.framework binary at "Version 3.6.9"
*** Building scheme "Alamofire watchOS" in Alamofire.xcworkspace
*** Building scheme "Alamofire iOS" in Alamofire.xcworkspace
*** Building scheme "OnePasswordExtension" in 1Password Extension Demos.xcworkspace

You could get more complicated and abstract the notion of desired build platforms, but that requires the individual authors to do more to support it, whereas this should be transparent to anyone who doesn't care.

@Zyphrax

This comment has been minimized.

Copy link

Zyphrax commented Oct 12, 2018

I'll add my use case here.

I'm working on a Swift library and it provides examples for iOS, macOS and tvOS. The examples require a bit of configuration (for example that building the example also builds any changes made to the library code) and I'd like to make the schemes shared so that I can commit them to GitHub.

A directive to skip building specific schemes in the Cartfile (of the library) would be great.

@sirghi

This comment has been minimized.

Copy link

sirghi commented Oct 16, 2018

From what I've skimmed through, this is a painful, long, and heated issue, so forgive me if I'm not fully aware of current state of things and the associated PR. I'll just add my use case and my 2 cents.

I'm developing framework A that relies on framework B, some schemes of which depend on other frameworks (C, D etc). Framework A only uses the scheme from B without dependencies. But every time I archive I have to wait for the other recursive dependencies to be built, which you have to agree, is painful (and when you're archiving caching doesn't help you there).

In my opinion, the solution to all of this boils down to adding subspec behaviour.

@KyleLeneau

This comment has been minimized.

Copy link

KyleLeneau commented Oct 16, 2018

@JetForMe What you are asking for can be done today by using the --platform parameter. You use case would look something like this:

// This will skip the build of tvOS and MacOS like you described, absence of the --platform property will build every public scheme.
carthage update --platform ios,watchos

@sirghi I agree with you and I would like to further limit publics chems from building with some opt-in behavior like --platform provides. The use case I have is that GRDB.swift has 7 targets/public schemes (GRDBiOS, GRDBWatchOS, GRDBMacOS, GRDBCipheriOS, GRDBCipherMacOS, GRDBCustomiOS and GRDBCustomMacOS). Carthage is only compatible with the first 5, the last 2 (custom) are for custom SQLite builds and can only be done with manual installation (submodule) or Cocoapods. I would like a way to either tell carthage what schemes to build like a whitelist or to specify an exclusion list, personally I think the whitelist is better for the project overall).

Here is what I would propose for syntax:

Currently (Base Line)

As is, build all public schemes (no breaking change)

github "Groue/GRDB.swift" ~> 3.4.0

// Build all targets and variants
carthage update

// Build all targets and only iOS variants
carthage update --platform ios

Option 1: Specify whitelist in Cartfile's

Add whitelist support to Cartfile syntax

github "Groue/GRDB.swift" ["GRDB", "GRDBCipher"] ~> 3.4.0

// Build all targets based on whitelist rules for entries and variants
// Would build: `GRDBiOS`, `GRDBWatchOS`, `GRDBMacOS`, `GRDBCipheriOS`,  and `GRDBCipherMacOS`
carthage update

// Build all targets and only iOS variants
// Would build: `GRDBiOS`, `GRDBCipheriOS`
carthage update --platform iOS

Option 2: Specify the dependences whitelist outside of the Cartfile's

Add whitelist support to the CLI to that it could be passed in via another file or input...

github "Groue/GRDB.swift" ~> 3.4.0

// Build all targets based on whitelist rules for entries and variants
// Would build: `GRDBiOS`, `GRDBWatchOS`, `GRDBMacOS`, `GRDBCipheriOS`,  and `GRDBCipherMacOS`
carthage update --only GRDB,GRDBCipher
// OR
carthage update --only target_whitelist_cartfile

// Build all targets and only iOS variants
// Would build: `GRDBiOS`, `GRDBCipheriOS`
carthage update --platform iOS --only GRDB,GRDBCipher
// OR
carthage update --platform iOS --only target_whitelist_cartfile

My Vote is on Option 1. I would actually like to see the Cartfile syntax be versioned in someway so this can be supported and maybe a yaml based syntax could be introduced for future extensions, but we can save that for another discussion.

@JetForMe

This comment has been minimized.

Copy link
Contributor

JetForMe commented Oct 16, 2018

For me, the key is to be able to specify it all in the Cartfile, so that a simple carthage update is all that's needed to build the minimum necessary for that specific project.

@mdiep

This comment has been minimized.

Copy link
Member

mdiep commented Oct 20, 2018

I think we would be okay with a whitelist approach if we could decide on an addition to our file format that would support this in a consistent matter. If anyone is interested in furthering this issue, I would suggest starting by researching the current Cartfile format and making a proposal about how this information could be added. OGDL has been considered in the past, but I don't think anyone has a good sense of what that would look like.

@sirghi

This comment has been minimized.

Copy link

sirghi commented Oct 23, 2018

For instance:
<schemeName(optional)> : <dependency(what we have now)> : <dependencySchemes(optional)>

And as, an example, this would be an app Cartfile:

github "apollographql/apollo-ios": "Apollo, ApolloSocket"

And the apollo-ios Cartfile would look like:

git "https://domain.org/framework.git" ~> 1.3 // common, would be used in any case
"Apollo" : github "gordon/chewbacca" == 1.2.1
"Apollo" : github "xverb/normalize" >= 3.5 : "Core"
"ApolloSQL" : github "stephencelis/SQLite.swift" ~> 0.11.5
"ApolloSocket": github "daltoniam/Starscream" ~> 3.0.5 : "Futures, Sockets"

In which case Carthage would pull in the first 3 and the last dependency from the apollo-ios Cartfile, resolving the transitive schema dependencies further down the stream. There's a bit of duplication, but still. And since the schema prefixes and suffixes are optional, this would seemingly be backwards-compatible with the current version of the Cartfile.

If you like this approach, we can move this to it's own ticket, or maybe #1876 ?

@ifndefgt

This comment has been minimized.

Copy link

ifndefgt commented Oct 24, 2018

I know this is not what you are looking for. But if your case is just filtering for platform targets, a simple script like this would help.

Steps:

    • Use bootstrap/update with --no-build. This is required for resolving dependencies all together.
    • Define separate lists for targets, like iOS-watchOS, iOS, watchOS
    • Build each list separately, but build order is important for getting benefits of cache. Thus, build inclusive lists first. For this example build iOS-watchOS first, then build iOS and watchOS (Otherwise your cache will just contain entries for iOS/watchOS, so you have to build the same things again and again)

Sample:

#!/bin/bash

############ DEFINITIONS ############

iOS_watchOS_Targets=('Alamofire')
iOS_Targets=(
     'lottie-ios'
     'KeychainAccess'
     'MBProgressHUD'
     'CocoaAsyncSocket'
     'AlamofireImage'
   )

function carthage_build_ios_watchOS {
     for i in ${iOS_watchOS_Targets[@]}; do
          carthage build ${i} --platform iOS,watchOS --cache-builds
     done
}

function carthage_build_ios {
     for i in ${iOS_Targets[@]}; do
          carthage build ${i} --platform iOS --cache-builds
     done
}

############ RUN SCRIPT ############

carthage bootstrap --no-build
carthage_build_ios_watchOS
carthage_build_ios
@mdiep

This comment has been minimized.

Copy link
Member

mdiep commented Oct 24, 2018

Please, let's discuss any format changes to the Cartfile in a new issue. If you have a proposal, open an issue or PR for it.

Any format change must be generally extensible. It cannot be limited to adding support for this one specific thing. If we make a change, we want to have the flexibility to support other things as well.

@Zyphrax

This comment has been minimized.

Copy link

Zyphrax commented Oct 26, 2018

Not a fan of putting the scheme name in front of the dependency. General approach in software is to put optional parameters at the end. I would prefer the Cartfile syntax of @KyleLeneau over that of @sirghi

It also seems a bit inefficient to me that every user of a library is going to have to specify the relevant schemes in their Cartfile. I would suggest that the library maker should (also) be able to specify which schemes are relevant. That way we can tell Carthage to e.g. always ignore example projects.

Maybe we could add a simple feature that shared schemes that start with an asterisk (or other symbol) are ignored by Carthage. This could be added to Xcode.swift - schemesInProjects, by adding a guard on the scheme name in schemes.filter.

public func schemesInProjects(_ projects: [(ProjectLocator, [Scheme])]) -> SignalProducer<[(Scheme, ProjectLocator)], CarthageError> {
return SignalProducer<(ProjectLocator, [Scheme]), CarthageError>(projects)
.map { (project: ProjectLocator, schemes: [Scheme]) in
// Only look for schemes that actually reside in the project
let containedSchemes = schemes.filter { scheme -> Bool in
let schemePath = project.fileURL.appendingPathComponent("xcshareddata/xcschemes/\(scheme).xcscheme").path
return FileManager.default.fileExists(atPath: schemePath)
}
return (project, containedSchemes)

@blender

This comment has been minimized.

Copy link
Member

blender commented Oct 26, 2018

#2294 has other ideas too.

I'm just leaving this here for an example of a yaml cartfile.

@sirghi

This comment has been minimized.

Copy link

sirghi commented Oct 26, 2018

Any format change must be generally extensible. It cannot be limited to adding support for this one specific thing. If we make a change, we want to have the flexibility to support other things as well.

One can only propose a change to overcome the problem they're aware of. Then, if the owners are aware of other problems, they might compile the suggestions into a discussion that would lead to a solution. I took the liberty of initiating it in #2627, if you don't mind

@Zyphrax Having schemes only at the end wouldn't help in filtering transitive dependencies of the library you're pointing to. Hence the pointed-to library specifies prefixes to show which scheme depends on which dependency (omitting the prefix for common deps). That being said, the need for a library-vendor to specify relevant schemes to be built in general seems legit too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.