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

Exclude specific schemes via Cartfile.ignore #1990

Open
wants to merge 11 commits into
base: master
from

Conversation

Projects
None yet
@Dschee
Contributor

Dschee commented Jun 15, 2017

Closes #1227, #437 and maybe more.

Goal

My goal ist to ensure that with a Cartfile that looks like this:

github "Moya/Moya"

Which would normally build Moya, RxMoya, ReactiveMoya, Alamofire, Result, RxSwift and ReactiveSwift. To introduce a new file named Cartfile.ignore with something like this content:

# Ignore RxSwift variant of Moya
scheme "RxMoya"
scheme "RxSwift"

# Ignore ReactiveSwift variant of Moya
scheme "ReactiveMoya"
scheme "ReactiveSwift"

Which leads to Carthage only building Moya, Alamofire and Result.

In detail the structure of the Cartfile.ignore is highly inspired by the structure of the current existing Cartfile. Instead keys like github and git the .ignore file should only support scheme.

scheme

This is the first step I want to reach – to ensure all schemes with the name specified after a scheme entry within the Cartfile.ignore are not built when running Carthage tasks. Note that the user is being notified about this with something like *** Ignoring scheme "RxMoya" in Moya.xcworkspace.

UPDATE NOTE: Originally I also had the suggestion to introduce a project keyword which would then even prevent from downloading the dependency. See the section "Where to go from here" below where I consider an alternative for that which can be added later on, in a subsequent PR.


Please also note, that since this change is purely additive, there should be no side effects whatsoever to any Carthage users who don't specifically create a Cartfile.ignore to use this feature.

Use the Cartfile.ignore right now via Carthage-Pro

I created a fork of Carthage until this gets merged (which might take years) which includes this feature already. Please read this comment further below for additional details.

Where to go from here

Here are a few "Next Steps" possible after this PR is merged to go further into this direction:

  • Add the possibility to ignore a dependency even during dependency graph resolution by adding support for entries like github "ReactiveCocoa/ReactiveSwift"
  • Consider the Cartfile.ignore in dependencies during dependency graph resolution so framework authors can improve the build time for their Carthage users without extra-work for them

@Dschee Dschee referenced this pull request Jun 15, 2017

Open

Skip schemes #1227

@Dschee Dschee changed the title from [WIP] Add support for Ignorefile to [WIP] Exclude specific schemes/projects via Ignorefile Jun 15, 2017

@Dschee Dschee changed the title from [WIP] Exclude specific schemes/projects via Ignorefile to [WIP] Exclude schemes/projects via Ignorefile Jun 15, 2017

@Dschee Dschee changed the title from [WIP] Exclude schemes/projects via Ignorefile to [WIP] Exclude specific schemes/projects via Ignorefile Jun 15, 2017

@BobElDevil

This comment has been minimized.

Contributor

BobElDevil commented Jun 15, 2017

So I do like the aspect that this is like "Cartfile.private" and only applies at the top level of the dependency graph when run. Then it's entirely the top level consumers job to figure out what they messed up, rather than multiple possibly incompatible dependency interactions. I'm not opposed to this, but I can't claim to be the official stance, so I'll defer on that.

Couple of comments on the actual structure though:

  • There's actually 3 levels to consider here, not just 2. It's not 'project and scheme', it's really something like 'dependency, project, and scheme', where dependency is what's defined in the Cartfile, project is the 1+ xcproj files found in the dependency, and schemes are any schemes therein.
  • With that in mind, I think we need to consider a different file structure, maybe YAML or json? Something that better supports a hierarchy. This way we can structure things at the granularity desired. For example given a Cartfile that contains github "example/MyRepo", I'm imagining rules along the lines (YAML for example purposes, any nested format would do)
# Ignore all schemes in all projects in MyRepo
- dependency: MyRepo

# Ignores schemes in MyProject.xcproj, but will not ignore other projects now because we've specified at the project level
- dependency: MyRepo
  projects:
    - name: MyProject.xcproj

# Ignores the MyTarget scheme of the MyProject.xcproj project, everything else in the dependency is not ignored
- dependency: MyRepo
  projects:
    - name: MyProject.xcproj
      schemes:
        - MyTarget

The other thing I'd like to see is somehow utilizing this to cover the other case of framework author wanting a scheme to never be built by carthage. The project/scheme specification would be identical in that case, the only difference is the rules of when to apply it. Maybe adding a special -dependency: current entry, or even just a top-level key current:, so we don't have the possibility of conflicting with a repo named 'current'.

At minimum, this file approach could be used for the latter as a stepping stone for the former

@BobElDevil

This comment has been minimized.

Contributor

BobElDevil commented Jun 15, 2017

Additionally I think we should limit the scope to just being a purely 'skip building this scheme' specification for now instead of also trying to skip it for fetching / cloning / resolution, as that gets into waterfall effects down to other dependencies

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jun 15, 2017

Thanks for the feedback @BobElDevil.

Actually I had thought about a more sophisticated YAML file at first, but then opted for a simpler solution. Also if you think that skipping the fetching/cloning/resolution part shouldn't be part of this PR (which I'm willing to agree on), then I think we don't even need the project option at all. Then I would suggest we just have a list of schemes to be ignored. Cause the only reason for me to add the project (or dependency) entry was to prevent the checking out steps, too. But you're right that those are not the biggest issue here as build time usually takes much longer than checking out etc.

So my suggestion is to keep my original approach using a non-yaml Cartfile.ignore and drop the project part entirely (those entries would be replaced with scheme instead). This should be relatively straightforward to implement and still should solve the most prevalent issue.

I'm not sure how my approach could be used to "utilizing this to cover the other case of framework author wanting a scheme to never be built by carthage" though. I think that we could initially start by inviting framework authors to extend their "Carthage installation" section in their README with a list of schemes that could be added to the Cartfile.ignore depending on the required feature.

For example Moya could state that users who don't want to use the features should add RxSwift, RxMoya, ReactiveSwift and ReactiveMoya to their listed schemes in their Cartfile.ignore. And AWS could have a list of all schemes and encourage their users to comment out those schemes with a # at the lines beginning that they actually want to use.

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jun 15, 2017

Note that I'll not have access to a computer until Monday, so I'll not be able to update the code to reflect any further discussed changes. But I'll try to answer on my phone to keep the discussion going.

@BobElDevil

This comment has been minimized.

Contributor

BobElDevil commented Jun 15, 2017

So my suggestion is to keep my original approach using a non-yaml Cartfile.private and drop the project part entirely. This should be relatively straightforward to implement and still should solve the most prevalent issue.

I still think you would need at least one level of depth, for repos that have multiple project files. It's possible that both projects have schemes with the same name, and if we only gave scheme names, then we'd filter out both or none. Though this could be accomplished by having the 'scheme' specification syntax be able to take a project file name along with it, e.g. ProjectFile/Scheme. Could even allow a 3rd layer that does specify the repository (repo/ProjectFile/Scheme), if you need that distinction. Doesn't quite have the flexibility of the rules you can achieve with a nested structure since you always need to specify down to the exact scheme, but this way we can keep the simpler file format by having a single line per specification.

I'm not sure how my approach could be used to "utilizing this to cover the other case of framework author wanting a scheme to never be built by carthage" though. I think that we could initially start by inviting framework authors to extend their "Carthage installation" section in their README with a list of schemes that could be added to the Cartfile.ignore depending on the required feature.

For example Moya could state that users who don't want to use the features should add RxSwift, RxMoya, ReactiveSwift and ReactiveMoya to their listed schemes in their Cartfile.ignore. And AWS could have a list of all schemes and encourage their users to comment out those schemes with a # that they actually want to use.

Sorry I was referring to my original suggestion for framework authors. I agree that in the cases you mentioned above, it would need to be some sort of recommendation from the authors to the users.

The use case I'm referring to is "I have a scheme that builds a bunch of extra stuff only needed for development, but it's shared so my coworkers can use it too". This is a scheme that no user would ever need to build, so it should be specified to be excluded by the framework author themselves. For example

# When running carthage from this repo, skip RxMoya. Don't skip it if this repo itself is being pulled in as a dependency
scheme "RxMoya"

# When the current repo is being built as a dependency, always skip MyDevelopmentScheme. This is limited to the current repo, this will not try to skip schemes located in nested dependencies.
scheme-current "MyDevelopmentScheme"

So once everything has been checked out, when carthage is about to run a build, it will filter all the schemes it finds by removing

  • any scheme found in the current repo ignore file specified via scheme
  • Any scheme found in the dependency being built's ignore file specified via scheme-current (I'm not attached to that naming though)

Note that these two cases can be tackled separately, I was only bringing up that they would want to use the same syntax and file format, so it makes sense to me that they'd end up in the same file, with some sort of marker to distinguish the usage

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jun 15, 2017

Yes, I agree that that would be a useful addition. But as you said it could be made in an additional PR. There the exact name could be discussed as well, but I would like to keep this PR lean and support the framework consumer side only.

Regarding the different projects, I‘m not sure what you mean. Could you show me an example framework where this would be required?

@BobElDevil

This comment has been minimized.

Contributor

BobElDevil commented Jun 23, 2017

Sorry it took so long to respond. But anyway, it's non standard, and I actually don't have an example that's not a private repo, but it is possible to name a scheme whatever you want, for example "Framework", and it doesn't have to match the target name. so you could have Framework1.xcodeproj and Framework2.xcodeproj both have a scheme named 'Framework', but it produces different targets (Framework1.framework, Framework2.framework). Without being able to specify which project file to filter, you'd have to filter both of them or none. So I was just trying to future proof it a bit by adding an extra level of clarity to the spec.

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jun 23, 2017

So rather than scheme we should use framework in the file? Is that your suggestion?

The reason I included scheme was that Carthage tells us when building the dependencies Building scheme "X" so I naturally thought there must be a list of schemes somewhere in the code which we can easily filter. If the same is true for frameworks as well, I have no problem with this change. But I'd like this PR to be as simple as possible, with a simple Cartfile.ignore structure and a simple implementation change. Cause otherwise I've got the feeling that this might not get merged too soon.

@BobElDevil

This comment has been minimized.

Contributor

BobElDevil commented Jun 23, 2017

I just meant prefixing your current scheme idea, specifying both project and scheme, to help differentiate. So from my example above you would say

scheme "MyFramework1/Framework" to skip the one scheme but not the other. It shouldn't add much complexity to this PR since at the point where we're getting schemes we know which project it came from

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jun 23, 2017

I see, makes sense. But it shouldn‘t be mandatory to specify both, it should still be possible to just list the scheme name. Then I‘m okay with your enhancement.

@BobElDevil

This comment has been minimized.

Contributor

BobElDevil commented Jun 23, 2017

yeah, that's ok with me 👍

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jul 21, 2017

Okay, sorry for not getting back to this the last few weeks, I've been on vacation and after that had some other work to get going the last few days (see my new project here).

Now this PR is the next thing I'd like to tackle, so expect some work on this until next week.

@Dschee Dschee force-pushed the Dschee:master branch from 99ed11a to 1399ccd Jul 27, 2017

@Dschee

This comment has been minimized.

Contributor

Dschee commented Aug 23, 2017

I've tried implementing this several times, but I just didn't succeed in filtering the schemes with the schemes from the Cartfile.ignore. I just couldn't find the right place for it and also I don't really understand how to deal with all the reactive stuff. @BobElDevil Would you mind helping me out there, maybe? That would be awesome!

@Dschee

This comment has been minimized.

Contributor

Dschee commented Sep 8, 2017

I really need this feature a lot, could anybody help me with the reactive part a little? I'm grateful for any help there ... @BobElDevil @mdiep @ikesyo

@flockoffiles

This comment has been minimized.

flockoffiles commented Jan 17, 2018

Is there any progress still expected on this PR? (Or it will be abandoned?)

@petester42

This comment has been minimized.

petester42 commented Apr 21, 2018

@Dschee im looking into continuing your work. What did you need help with? Implementing the logic of skipping schemes?

@Dschee

This comment has been minimized.

Contributor

Dschee commented Apr 22, 2018

@petester42 Yes, exactly. My problem is that I never used reactive programming, therefore I'm having troubles to find the right place to actually filter / ignore the schemes found in the Cartfile.ignore. Also, I have no idea, where the Cartfile.ignore should be read, how I get the answer from the reactive stuff and where I can find the list of Schemes to filter. To me, all of the code looks like Russian: I can read most letters, but the meaning is different than I assume.

I just rebased my fork so there are no conflicts with the base branch. Feel free to fork my fork and post a PR to my fork. Then I can merge and update this PR. Thank you for your help, @petester42!

@Dschee Dschee force-pushed the Dschee:master branch from c273d13 to 5ee810d Jul 4, 2018

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jul 4, 2018

@blender I just added the error for other cases than one or two components just as requested. Also I just rebased the branch again so this can be merged at any time.

In addition to that, since I rebased, I released a new Version (1.1.0) of Carthage-Pro – just run brew upgrade carthage-pro if you have the previous version installed.

@mdiep mdiep referenced this pull request Jul 24, 2018

Open

Schemes and Carthage #2529

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 24, 2018

Okay, I've opened #2529 with my thoughts about the problem of unwanted schemes for Carthage members to discuss.

Having said that:

  1. I think the design in this PR is insufficient. Listing schemes without the dependencies they came from is not enough.

  2. I don't think Carthage should solve this problem. This is an optimization. As I've said in #2529, I don't believe this is the right direction for Carthage to take.

So I believe we should close this PR. But we will see what the other Carthage members think.

@Dschee I also think you should change the name of your fork and tap. Carthage Pro suggests an affiliation with this project and your fork doesn't have any affiliation.

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jul 24, 2018

Locking me out from the discussion in #2529, telling my (perfectly working) solution is "insufficient" and simply delegating the responsibility to "Xcode and SwiftPM to solve (this problem) down the road", and on top of that, asking me to rename my fork so it doesn't sound like it has anything to do with Carthage although it's a fork of it?

I never expected that your answer which took long enough could be so disappointing ...

I really don't understand why you guys don't want to solve this very apparent problem in a pragmatic way. My solution was only one possible way, there are others of course, but having an "insufficient" solution is still better than just waiting for others to solve this for you. And actually I did solve this problem for you, so you even didn't have to do anything except reviewing and merging. That's why I really don't understand what's going on here.

Did I insult anybody and this is your way of revenge? Have I been too impatient by reminding you of this issue every few months? If so, I'm really sorry. And I also really like the idea that Carthage makes steps to get compatible with SPM or even use it sometime in the future. But I don't see why that should hold us off from solving #1227 right now with a pragmatic approach ...

@RuiAAPeres

This comment has been minimized.

RuiAAPeres commented Jul 24, 2018

It would be useful as well to get some feedback from @jdhealy. The PR was rejected, but without a reason.

@blender

This comment has been minimized.

Member

blender commented Jul 24, 2018

@Dschee I can assure you sentiments are kept well separated when reviewing a pull request. That would be a silly thing to do especially in a welcoming community like the one we work in.

Enthusiasms can sometimes be misunderstood but patience goes a long way.

@jdhealy

This comment has been minimized.

Member

jdhealy commented Jul 24, 2018

@RuiAAPeres, part of what I was stumbling over putting into words is what Matt refers to with “two issues at play” of both the “framework author problem” and the “framework consumer problem” — definitely a need to consider those in light of each other.

Evaluating (for ignore-behavior) scheme names without anything else associated with them is a concern I share as well.

Maintaining a blacklist of skipped scheme names, which would have to be updated when a desired-to-be-skipped scheme gets added or renamed in a repo, is a friction that gave me pause. There are nuances with this aspect of this kind of solution to the “framework consumer problem” which I don’t have quite have the words for yet. Apologies for not finding the time to gather my thoughts.

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 24, 2018

Locking me out from the discussion in #2529, telling my (perfectly working) solution is "insufficient" and simply delegating the responsibility to "Xcode and SwiftPM to solve (this problem) down the road", and on top of that, asking me to rename my fork so it doesn't sound like it has anything to do with Carthage although it's a fork of it?

You're welcome to give your feedback here or in the other open issues. I opened (and locked) #2529 so that the core team can discuss the issue. That doesn't mean your opinion is unwelcome or unwanted. But there is a need for the core team to be able to discuss by themselves.

Your solution is working perfectly for you, but that does not mean that it's working perfectly. "Works on my machine" is not very helpful—especially for projects like Carthage that support a variety of work flows and a large number of external variables.

I noted that you haven't sufficiently identified schemes. I believe that the nesting of these exclusion files may also be underdeveloped.

I really don't understand why you guys don't want to solve this very apparent problem in a pragmatic way. My solution was only one possible way, there are others of course, but having an "insufficient" solution is still better than just waiting for others to solve this for you. And actually I did solve this problem for you, so you even didn't have to do anything except reviewing and merging. That's why I really don't understand what's going on here.

I appreciate you opening a PR to attempt to fix this issue. But:

  1. I repeatedly told you that I didn't think Carthage should solve this problem. Rather than engaging in a discussion, attempting to convince me and solve the underlying design issues, you ignored me and opened a PR with how you thought it should work.

  2. Writing code and opening a PR is by far the easiest part of this project. To say "you even didn't have to do anything except reviewing and merging" completely misunderstands how a large OSS project like this operates. The core team is responsible for what ships. You may have written code, but the team needs to understand it, accept responsibility for it, and maintain it going forward. That is by far the bigger task.

This is exactly why I chose to lock the discussion in #2529. I'm happy to discuss this issue with you, but this back-and-forth about your specific implementation, the timeline, etc. would sidetrack from that discussion. That's why I wanted to keep this separate.

@mluisbrown

This comment has been minimized.

mluisbrown commented Jul 24, 2018

I have to say I find @mdiep's reaction very disappointing:

  • The issue that this PR tries to solve is clear and present, and has been raised many, many times.
  • The PR has been open for more than a year, without anyone in the core team raising any of the issues that Matt has now suddenly raised (at least as far as I'm aware).
    EDIT: the issue was discussed in #1227, although my reading of that doesn't suggest that any PR would be a futile endeavour, merely that the core team had some reservations and other priorities.
  • Then when the code has been reviewed, and it looks like we might be getting somewhere, the entire purpose of the PR is unceremoniously dumped on, and to make matters worse, a private issue is created where only the core team are allowed to discuss it.
  • The problem at hand continues and any solution is hand waved away to "one day this will be handled by SPM" 😕

Quite frankly, any potential contributor to this project seeing this PR would likely not want to touch it with a 10ft barge pole. I mean, with this attitude why is Carthage even OSS?

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 24, 2018

The PR has been open for more than a year, without anyone in the core team raising any of the issues that Matt has now suddenly raised (at least as far as I'm aware).

The core design issue was discussed in #1227 several times—before this PR was even opened.

Mar 13, 2017:

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

June 14, 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.)

June 14, 2017:

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.

There are several more responses after that.

Quite frankly, any potential contributor to this project seeing this PR would likely not want to touch it with a 10ft barge pole. I mean, with this attitude why is Carthage even OSS?

I hope that's not the case. 😞 We love getting contributions.

Here's the takeaway I'd want everyone to have: for significant contributions, build consensus with maintainers before coding and opening a PR. A PR is one approach to solve a particular problem. That approach may not be the best approach to solving that particular problem. It's best to have agreement on the approach before doing it.

@blender

This comment has been minimized.

Member

blender commented Jul 24, 2018

@mluisbrown

The PR has been open for more than a year, without anyone in the core team raising any of the issues that Matt has now suddenly raised (at least as far as I'm aware).

That's why multiple people review PRs...

Then when the code has been reviewed, and it looks like we might be getting somewhere, the entire purpose of the PR is unceremoniously dumped on, and to make matters worse, a private issue is created where only the core team are allowed to discuss it.

As you can see discussion is going on here too. No one is taking away you're ability to express your opinion as you're doing. I started the review process to get the discussion going. A civil discussion. I take full responsibility for this.

Quite frankly, any potential contributor to this project seeing this PR would likely not want to touch it with a 10ft barge pole.

I find this statement short sighted. Is there a rule somewhere projects should accept every PR they get? Also, instead of doing the work before discussion and then arguing, why not discuss the intentions ahead of coding? I don't believe you normally work this way, do you?

I mean, with this attitude why is Carthage even OSS?

Again, I find this statement short sighted too. It's a community tool built by everyone's effort. You can fork it and remix it just like @Dschee has done. It's also under MIT licence so you can literally copy the code and use it to make your commercial tool.

@brow

This comment has been minimized.

brow commented Jul 24, 2018

I'm hoping to contribute to Carthage someday, and I do not feel discouraged by this thread. I think all parties are reading and responding thoroughly, even when (I suspect) they're feeling frustration. I can see this is a high-quality community.

I especially appreciate the time that @Dschee, @mdiep, @BobElDevil, and @blender have invested in communicating their thoughts.

I see several active topics in the most recent discussion:

  • Will this PR be merged into Carthage? Could it be merged with some additional changes?
  • Should there be a fork of Carthage while the PR is not merged? What name is appropriate for a fork?
  • Is the way that Carthage generally handles contributions working well?
  • Is this contribution being handled in the same way as Carthage generally handles them?
  • What is the purpose or meaning of having a collaborators-only discussion in #2529?
  • Have I been mistreated in this interaction? Will I be mistreated this way in the future?

I think it will be difficult to make progress on all of these topics in the same thread. If you are actively participating in this thread:

  • Which of these topics is your highest priority?
  • Would you be willing to ignore the other topics and post specifically about that topic?
  • Would you be willing to take a short break from posting and see what feels most important to you in one or two days?
@mluisbrown

This comment has been minimized.

mluisbrown commented Jul 24, 2018

@blender

Is there a rule somewhere projects should accept every PR they get? Also, instead of doing the work before discussion and then arguing, why not discuss the intentions ahead of coding?

Of course not. @Dschee's intentions were clear before doing the work and this had been discussed. There's nothing in the discussion that says anything that might indicate a PR for this issue would get shut down. The core team had reservations, sure, and they had other priorities, but no more than that.

This PR addresses a clear need felt by many users of Carthage, it's not some random feature. What incentive is there to contribute to a repo where this kind of PR gets basically closed after all the work has been put in?

No discussion of ways in which it could be improved, issues with the implementation, etc. Just: "Sorry, it's a no. Core Team will discuss this issue privately"

@brow

The 2 topics that are of the highest priority to me are:

  • Will this PR be merged into Carthage? Could it be merged with some additional changes?
  • Should there be a fork of Carthage while the PR is not merged? What name is appropriate for a fork?
@blender

This comment has been minimized.

Member

blender commented Jul 24, 2018

@mluisbrown I think you missed

So I believe we should close this PR. But we will see what the other Carthage members think.

Also: #1990 (comment)

@Dschee

This comment has been minimized.

Contributor

Dschee commented Jul 25, 2018

I'm not going to react to all things said here anymore since I think I already made my point. The rest is left to Carthage contributors.

But going forward, what I care most (and always have) is that the issue #1227, which is basically about unnecessarily long build times when bootstrapping a new project, is solved somehow. I work for an agency which means we have many different projects and we need to change between different projects very often and thus need to bootstrap a new project quite as often. Since we are using Moya in nearly all projects, but also AWS in some, it is really frustrating to not only "grab a coffee" when waiting for Carthage bootstrap, but instead have to wait half an hour. And if something fails along the way (the RX libraries – which we don't use – tend to do so), we need to check the problem and react somewhere within those 30 minutes, which makes this even more frustrating.

So, as I already stated a few times, I don't really care about what the solution looks like, I just want this issue to be solved sooner rather than later. And any comment that basically reads like "we don't plan to solve this (soon)" will make me unhappy – @mdiep being the one to be the worst in this regard, as he doesn't want to solve this issue at all – and every comment in favor of a pragmatic approach that will actually solve this issue will make me happy.

And one last thing about why I might have overlooked what @mdiep said about this not being an issue of Carthage: I'm also a quite active Open Source contributor and project maintainer myself, so I know what it means to be one. But when I developed a tool which many people seemed to use, I felt a resposibility for those people and so long as multiple people reported about an issue about my tool – even if it didn't affect me or the ways I thought my tool should be used – I still tried to help them as good as I can to fix it without changing the core goal of my tool.

Since many people have reported about this issue times and times again, I was convinced (and I am still) that this is such an issue where the users of this great tool need something the contributors might not feel like is "core part" of their tool. But I had confidence in the feeling of responsibility of the contributors. This is exactly what I cannot understand here. Thus all comments basically saying "we know, many are reporting this problem, but we don't care" by not actively helping to solve this problem, are against my worldview and are also the reason why I agree with @mluisbrown that this is not a good sign regarding having an active and open community.

For one, I currently feel like, I would rather write my own dependency manager instead of improving Carthage ever again. And that's actually my plan now, so expect to see an alternative to Carthage from me sometime around this fall ...

@mluisbrown

This comment has been minimized.

mluisbrown commented Jul 25, 2018

Since I can't comment in #2529 I have to comment here 🙈 :

@blender

Work to support SwiftPM packages

Definitely. However I think Carthage can be more. Also SwiftPM has no support for iOS, tvOS, or watchOS.

For many SwiftPM projects just running swift package generate-xcodeproj first will be sufficient to then be able to build the project with Carthage. For example: https://github.com/pointfreeco/swift-prelude

swift package generate-xcodeproj
carthage build --no-skip-current --platform macOS

Will build the project no problem (--platform iOS doesn't work in this case because the test targets use libraries not available in iOS, but that's a separate issue).

But this is orthogonal to the issue at hand. This particular project has a bunch of frameworks, which are all built (swift package generate-xcodeproj just creates a single scheme which builds everything in the project). The "just build the stuff I need" issue remains.

Also, this doesn't address the vast majority of projects used in iOS / macOS development which don't have SwiftPM support.

So sure, supporting SwiftPM packages is definitely something Carthage should be thinking about, but it won't solve this issue, and it's an issue that needs solving.

Overall I think that this is a very real problem. Just like the .private, the blacklisting does not travel upwards so there is no risk for other consumers.

It is true that this might not be a problem for Carthage to solve, but I would also say that there are many other problems, starting with the lack of strict rules on how developers set up their projects, that carthage had made it's own. The complexity added by this change is negligible in my opinion.

👏

@mdiep

This comment has been minimized.

Member

mdiep commented Jul 25, 2018

So sure, supporting SwiftPM packages is definitely something Carthage should be thinking about, but it won't solve this issue, and it's an issue that needs solving.

I wasn't saying that Carthage should use swift package generate-xcodeproj. I was suggesting that we use the information from Package.swift instead of adding more information to the Cartfiles.

@mluisbrown

This comment has been minimized.

mluisbrown commented Jul 26, 2018

I wasn't saying that Carthage should use swift package generate-xcodeproj. I was suggesting that we use the information from Package.swift instead of adding more information to the Cartfiles.

Ok, that seems like a good idea. However, as has already been mentioned, even if working with SwiftPM could, in the future, solve the issue at hand, it's not a realistic to expect people having this issue to wait until then. They will either need to use a fork or abandon Carthage as a dependency manager altogether.

@zdnk

This comment has been minimized.

zdnk commented Aug 16, 2018

Well, is this feature coming or not? I don't see it benefit anyone discussing it for another year.

I agree with @Dschee. Having long build times costs us a lot of money and it is honestly annoying. Our build times could be decreased so significantly if we could just ignore those schemes that we don't need.

@freak4pc

This comment has been minimized.

freak4pc commented Nov 28, 2018

Sorry for "upping" this and being late to this conversation but I actually like what @mdiep suggested in the "collaborators" thread. Whitelist and not Blacklist - and it definitely needs to take the repo in question. As simply ignoring a scheme without the dependency would lead to chaos in deep-dependency graphs.

#2529 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment