Would like to setup Carthage Deploy artifacts on Travis

[KyleLeneau]

Hey @groue ,

This is mostly a question for you on how I should proceed with something I have been thinking of. To help with the Carthage support I would like to change the release process so that when releases are tagged there is a proper release page in Github with the Changelog for the tag and importantly uploaded build artifacts from Carthage deploy step... In order to do this though I need to setup travis to use a "machine" / "ci" user and access token to interact with the API. I wanted to get your opinion on how to proceed with that and if you have any ideas on how that could be setup and maintained.

I have done this for my current company and posted with Github, Gitlab using CircleCI or Bitrise or homegrown scripts so I am not worried about the technical work. I have limited use with Travis so it will take some learning but I know how to do the rest. I am probably going to follow this guide a bit and tweak as I learn Travis CI: https://github.com/Carthage/Carthage#use-travis-ci-to-upload-your-tagged-prebuilt-frameworks

Anyways, wanted to get your opinion. Also, I didn't know the best way to connect with you on this so I hope an issue works out, feel free to close this or connect with me another way.

Thanks,
Kyle

[groue]

Hello @KyleLeneau,

Unlike CocoaPods which is a tool which helps both library users and library authors, Carthage expects library authors to do its job, and does a poor job at helping library users. Carthage users who want GRDB, currently, fork the GRDB repo, and tweak the meat until Carthage can do its job.

I don't like this tool, and I don't like spending time and energy they should spend. My job is providing a SQLite library, with documentation for reliable installation methods. Carthage is not one of them: it is described as "not supported" in the main README.

I'm sorry they're understaffed, and don't listen to reasonable feature requests. That's not my problem.

End of the rant.

Now the answer you ask for: since I don't want to maintain workarounds for Carthage, I'll need a maintainer who is committed to long-term support whenever such workaround ships in the main repo. I'm bloody serious when I say "long-term support".

[groue]

There are only two real fixes to this issue, of course:

• Fix Carthage
• Stop using Carthage until it is fixed

I really don't like this pressure to integrate workarounds just because people insist on using a broken tool.

[groue]

For f***'s sake, we'd need to produce binaries for each supported Xcode version/Swift ABI (reminder: we're still supporting Xcode 9.3+) The more I think about it, the crazier I find this idea.

[groue]

Oh, and how many people have to implement those workarounds, just because Carthage maintainers do not? Doesn't it sound like an unfortunate energy spill? Are contributors of open-source libraries supposed to spill their time because they are nice? Who will maintain the script as new Xcode and Swift version ship? Who will support users who have troubles, and not only acknowledge, but FIX their troubles?

The number of open issues in GRDB is usually very low, for three reasons: this library is maintained, does not over-promise, and it is possible to fix user issues because all documented stacks are reliable from top to bottom. This is my recipe for a trustable and sustainable open source library, with as few opportunities as possible for maintainers to be burnt, and as few opportunities as possible for users to be disappointed.

[groue]

With my framing of the topic, one can wonder where is the room for experimentation, where is the "edge" version of the lib, how it is possible to move on, how we can provide to the users who are willing to move fast and break things their fix of technical hotness.

I'm perhaps over cautious, in my attempts at keeping the complexity of the project under (my?) control.

I'm wondering what people with more experience of open source think. May I ask for your advice, @KyleLeneau, @freak4pc, @SD10?

[SD10]

We currently use GRDB + Carthage by forking this project and tweaking it as needed. This is something I've just grown to accept with Carthage.

Everyone has different opinions on this topic, but I don't believe it's the job of library maintainers to work around shortcomings in a "package manager". Fwiw, we're actually migrating to CocoaPods because of this.

I'm sorry they're understaffed, and don't listen to reasonable feature requests. That's not my problem.

I'm very bitter in regards to how they've handled this as well.

For f***'s sake, we'd need to produce binaries for each supported Xcode version/Swift ABI (reminder: we're still supporting Xcode 9.3+)

This isn't a scalable solution without ABI stability. I believe we provided prebuilt binaries for Moya and then decided to abandon this approach because it led to so many problems/confusions by users.

[freak4pc]

I side with @groue.
The worst side of supporting users as an Multi-OSS -projects maintainer is supporting Carthage users. It's absolutely riddled with issues that are beyond the scope of a "stay out of my way" style dependency manager.

When the project is small I could see how supporting Carthage via patches is somewhat OK, but for a large project like this, with backwards compatibility as early as Xcode 9.3, supporting Carthage beyond the "defaults" would be impossible. (Or just really not worth it, mostly).

Pre-built binary are all nice and fun but until there's ABI stability they are practically useless to anyone not using the same version as the prebuild binary.

[groue]

Many thanks to @SD10 and @freak4pc for your experience and precious feedback!

@KyleLeneau, I hope those balanced voices did not cool you down. Let me try to sum up the situation:

Carthage creates a strong pressure on repository maintainers, who have to solve various support issues, without any guarantee of success. Carthage is not an easy toy, and not a one-size-fits-all solution. It's made for power-users and people who are willing to support themselves. Those people currently fork the GRDB repository, and perform their own setup and maintenance.

This may be the best option for you, too, at the present time.

I'll help supporting Carthage (I already did: #408, #202, groue/sqlcipher#1), but not by committing myself and GRDB to official Carthage support and maintenance. I can only change my mind when someone emerges and takes over both.

[KyleLeneau]

Thanks for all the feedback, I am finding the 1) updating carthage (contributing to the source) is going to take longer, it's on my goals to do but to make what I want to work I need to re-write how Carthage manages the files... 2) for my personal project that is using GRDB I find it easier to just use carthage to manage the submodules and then setup a workspace.

[yccheok]

If I already using Carthage in my current half-way-done project, and I would like to start applying GRDB.swift, does that mean my only choice is to do it "Manually"?

Note, I do not have plan to switch away from Carthage (as it already works for other libraries), and I have no intention to fork GRDB.swift to make it works with Carthage (As I don't have knowledge to do so).

Thanks.

[groue]

@yccheok you'll get free support as long as you stay in the documented requirements. Carthage is not part of them. Your question requires a high amount of time and enquiry in order to get its answer: it definitely crosses the limit. You may perform your own exploration, or look for an answer on Stack Overflow.

[freak4pc]

“ Note, I do not have plan to switch away from Carthage (as it already works for other libraries), and I have no intention to fork GRDB.swift to make it works with Carthage (As I don't have knowledge to do so).”

Read: I’m not going to lift a finger to help myself, please spend some of your time as a OSS maintainer to solve my very specific problem for free, and I won’t even say thanks.

Geez, maintaining OSS is such a thankless job.

[groue]

I feel lucky, as a matter of fact :-) The signal-to-noise ratio is quite high here, generally speaking (I don't know why).

I can handle a few young wolves, but I appreciate your friendly bite, @freak4pc 😚

[KyleLeneau]

@freak4pc Your best bet if you want to use Carthage with GRDB.swift is to use the --use-submodules option on Carthage and then drag in the GRDB project file to a workspace. This is how I have my projects setup now after enough messing around with Carthage, Xcode versions and new toolchains. i.e. Using Carthage to manage git submodules is about the best solution I have found so far after years of trial and error.

[groue]

Thanks @KyleLeneau :-) I must warn any user who thinks this is the solution to the "Carthage problem" that in all GRDB submodules, three are only used for GRDB tests, and one is only used for Custom SQLite Builds. In all GRDB shared schemes, two are dedicated to tests. All of this makes Carthage perform a lot of work that has nothing to do with the integration of GRDB in an application. Besides, those schemes are not vetted against command-line builds, which means Carthage may fail at building them (it has revealed true if many occasions, when I was still thinking I had to do something about it, despite the efforts of nice people (#262, for example)).

To anyone listening: don't rush, and don't complain if it doesn't work as you expect. Carthage will remain unsupported until somebody stands up and commits to long-term support (a very unpleasing demanding job, so I wouldn't bet on it). And even if there exists a recipe which involves forking GRDB in order to remove the extra cruft and spare network bandwidth, disk space, CPU cycles, and CI time, nobody has ever thought sharing his technique ¯\_(ツ)_/¯. Opting for Carthage is opting for the bleeding edge of the universe. In space, no one can hear you scream.

Anyone looking for inspiration may find the gem he's after in the GRDB Github network. It definitely looks like several users are maintaining (or not) their customized Carthage-dedicated forks.

[Jeehut]

@groue I just happened to come across this thread and I'm really impressed by your clear mind on this topic. 🥇 👍

As the author of Accio (a tool that aimed to fix some of Carthage's issues) I wish I had the same clarity back then and would have ditched Carthage all over from the start. But at least I was wise enough to build the tool on top of SwiftPM and use the same package format, so all in all it helped some open source projects support SPM faster and it's deprecated since Xcode 12 anyways. So I guess, all's well that ends well. :)

Thank you for this great library, I just read the documentation and it's definitely one of the best I've read so far. 💯
Will try it out in my next app as Apple still didn't release the replacement for Core Data we're all waiting for (maybe not you).

[groue]

Thank you @Jeehut :-) I've tried to support Carthage, since users were asking for it. And one day, yes, I figured out this was not a reasonable option. Now users are requesting an XCFramework. I'm more optimistic about this one :-)

[andre-tirta]

now its 2024, do the above mentioned issues still hold true for carthage?

[broken-bytes]

@andre-tirta Carthage is a horrible tool. If you can, go with SPM or Cocoapods. Carthage adds complexity to your project with zero benefits