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
Conversation
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:
# 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 At minimum, this file approach could be used for the latter as a stepping stone for the former |
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 |
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 So my suggestion is to keep my original approach using a non-yaml 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 For example Moya could state that users who don't want to use the features should add |
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. |
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.
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
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
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 |
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? |
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. |
So rather than The reason I included |
I just meant prefixing your current scheme idea, specifying both project and scheme, to help differentiate. So from my example above you would say
|
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. |
yeah, that's ok with me 👍 |
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. |
I've tried implementing this several times, but I just didn't succeed in filtering the schemes with the schemes from the |
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 |
Is there any progress still expected on this PR? (Or it will be abandoned?) |
@Dschee im looking into continuing your work. What did you need help with? Implementing the logic of skipping schemes? |
@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! |
@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. |
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 appreciate you opening a PR to attempt to fix this issue. But:
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. |
I have to say I find @mdiep's reaction very disappointing:
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? |
The core design issue was discussed in #1227 several times—before this PR was even opened. Mar 13, 2017:
June 14, 2017:
June 14, 2017:
There are several more responses after that.
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. |
That's why multiple people review PRs...
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.
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?
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. |
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:
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:
|
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" The 2 topics that are of the highest priority to me are:
|
@mluisbrown I think you missed
Also: #1990 (comment) |
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 ... |
Since I can't comment in #2529 I have to comment here 🙈 :
For many SwiftPM projects just running
Will build the project no problem ( But this is orthogonal to the issue at hand. This particular project has a bunch of frameworks, which are all built ( 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.
👏 |
I wasn't saying that Carthage should use |
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. |
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. |
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. |
2 years later and still no solution, should have gone with cocoapods :( |
Hello everyone, I finally managed to bring my own dependency manager to life which fixes the issues we've had with Carthage in our team. It's mainly based on SwiftPM and also currently uses Carthages Please also note that I'm already making many popular Swift frameworks compatible myself to provide a bunch of frameworks that are already officially compatible. The name of the new tool is Accio (like the summoning charm ✨ in Harry Potter). It's main advantages over Carthage as of now are:
Please check it out here: Feel free to open issues if you encounter any problems with it or if you have ideas on how it can be further improved to make dependency management a less nerve-wrecking task for everybody. I would also like to take the chance to thank all contributors of Carthage who all together made this great tool possible and drove the entire community forward. I hope my tool helps to fill the gap between the time where Carthage alone was used for dependency management and the future time (which I suppose to be late 2020) where SwiftPM & Xcode will take over the entire dependency management task. Until then, let's add Cheers! 🍻 |
The text was mainly copied over from my comment here: Carthage/Carthage#1990 (comment)
Closes #1227, #437 and maybe more.
Goal
My goal ist to ensure that with a Cartfile that looks like this:
Which would normally build
Moya
,RxMoya
,ReactiveMoya
,Alamofire
,Result
,RxSwift
andReactiveSwift
. To introduce a new file namedCartfile.ignore
with something like this content:Which leads to Carthage only building
Moya
,Alamofire
andResult
.In detail the structure of the
Cartfile.ignore
is highly inspired by the structure of the current existingCartfile
. Instead keys likegithub
andgit
the.ignore
file should only supportscheme
.scheme
This is the first step I want to reach – to ensure all schemes with the name specified after a
scheme
entry within theCartfile.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
.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:
github "ReactiveCocoa/ReactiveSwift"
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