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

Would like to setup Carthage Deploy artifacts on Travis #433

Closed
KyleLeneau opened this issue Oct 19, 2018 · 15 comments

Comments

@KyleLeneau
Copy link
Contributor

commented Oct 19, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 19, 2018

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 groue added the question label Oct 19, 2018

@groue

This comment has been minimized.

Copy link
Owner

commented Oct 19, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 19, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 19, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 19, 2018

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

This comment has been minimized.

Copy link
Collaborator

commented Oct 19, 2018

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

This comment has been minimized.

Copy link

commented Oct 19, 2018

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

This comment has been minimized.

Copy link
Owner

commented Oct 23, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Oct 24, 2018

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

This comment has been minimized.

Copy link

commented Aug 6, 2019

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

This comment has been minimized.

Copy link
Owner

commented Aug 6, 2019

@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

This comment has been minimized.

Copy link

commented Aug 6, 2019

“ 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

This comment has been minimized.

Copy link
Owner

commented Aug 6, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 9, 2019

@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

This comment has been minimized.

Copy link
Owner

commented Aug 9, 2019

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.

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