Live data from Hacker News

CocoaPods trunk read-only plan

blog.cocoapods.org

91–100 of 116 posts

Re: CocoaPods trunk read-only plan

#91

Earlier quoted context omitted.

Right, but you can’t have a single package containing both ObjC and Swift. It’s a limitation of SwiftPM that has prevented me from using it for a few projects (I am using it in several others, though).

You can mix them, it just has to be released as a binary framework which is a bit annoying as I would prefer a pure source release but it does work.

Since it clearly wasn’t obvious, I was asking in the context of a package consumer, not publisher.

My involvement with MacOS development is somewhat limited and I have no plans publishing any packages yet ;)

Re: CocoaPods trunk read-only plan

#92

Earlier quoted context omitted.

You can mix them, it just has to be released as a binary framework which is a bit annoying as I would prefer a pure source release but it does work.

Since it clearly wasn’t obvious, I was asking in the context of a package consumer, not publisher. My involvement with MacOS development is somewhat limited and I have no plans publishing any packages yet ;)

Oh gotcha, yeah they’re absolutely usable as any maintainer mixing the languages and providing SPM support will handle the binary release part. If anything it’s nicer for the consumer (binary releases in general) as it cuts down on full app rebuild times.

Re: CocoaPods trunk read-only plan

#93

Earlier quoted context omitted.

I don’t know, I’ve never had those problems and my codebases reach 600k+ LOC. I’ve certainly had plenty of errors to deal with Cocoapods and obsolete frameworks though, though those projects also tend to use pretty much every third-party lib that gets attention on Medium. Modularizing an Xcode project with local Swift packages has been the best productivity gain in my experience. Doing something similar with Cocoapod…

Local Swift packages are indeed improving the experience a little bit: better version management, less xcode crashes, slightly more explicit errors, but still highly troublesome. It really feels like Apple's teams are not using any of SwiftPM themselves.

> It really feels like Apple's teams are not using any of SwiftPM themselves.

They probably never will, at least not for anything that ships with the OS. For Apple, binary size is very important, and it’s essential that they have only one of every library (“project”) installed on the device, and that they use dynamic linking everywhere.

SwiftPM uses static linking to the core, and if Apple were to use it, binary sizes would balloon (not to mention there would be potentially mutually incompatible versions of things.) You could fix this by ignoring version specs in the package file and building just one of every project/framework, and changing it to use dynamic linking everywhere… but at some point you’re just contorting swiftpm to become a big mono-build system, which only Apple would really be using as such.

Re: CocoaPods trunk read-only plan

#94

This is really sad, because the replacement, Swift Package Manager, is really crap: it lacks some useful features (an "outdated" command, meaningful commandline output, ...), is buggy as hell in xcode (most of the time xcode just crashes when you add/removed a dependency, error messages while getting a repository are not understandable and even often not visible entirely, many repositories have some old Package.swift…

If you're looking for an outdated command, maybe this works for you? https://github.com/kiliankoe/swift-outdated/

Disclaimer: I wrote this (a while back)

Re: CocoaPods trunk read-only plan

#95

And this, kids, is why you should always vendorize your dependencies

There may be good reasons to do that, but this isn't one. Any project using CocoaPods will still remain working for the foreseeable future - you'll just not get new updates to dependencies at some point. And at that point you can migrate to SwiftPM or vendored dependencies, without losing anything.

Good idea let's punt it to 20 years from now when the CocoaPods server goes down. By then the startup will have been acquired and we will be long gone, so it's the parent company's problem not ours.

Re: CocoaPods trunk read-only plan

#96

Earlier quoted context omitted.

Another non-iOS developer here. It was absolutely not clear what you meant with a single word reply, and one that honestly looked like a typo or some kind of insult (short + -ist) I didn’t get.

What I meant is that people who are non-ableist, non-racist, etc. do not have racism et al. popped up in their mind. Why does everything have to do with those things in people's minds? It is tiring, and I am starting to believe they are the racists. It never crossed my mind based on the name of a project. It is ridiculous.

If you’re not familiar with the experience of browsing the internet and then suddenly having deeply-held parts of your identity deemed undeserving of respect, it’s the kind of thing that the mind naturally develops habits to avoid, in much the same way that you might start to walk differently through a city after getting mugged. It is indeed tiring for everyone, but the solution is not to blame people for doing what they feel like they need to do to protect themselves.

Re: CocoaPods trunk read-only plan

#97

Earlier quoted context omitted.

Yes. There's no ambiguity, no other project uses the name

It was not at all obvious to people that haven’t heard of tuist (presumably the intended audience of your post) that tuist is a product. I thought it was a typo or even possibly an insult (same form as racist, sexist, ableist, ageist, etc)

Glad we've cleared it up

Re: CocoaPods trunk read-only plan

#98

This is really sad, because the replacement, Swift Package Manager, is really crap: it lacks some useful features (an "outdated" command, meaningful commandline output, ...), is buggy as hell in xcode (most of the time xcode just crashes when you add/removed a dependency, error messages while getting a repository are not understandable and even often not visible entirely, many repositories have some old Package.swift…

My biggest criticism with SPM is that there doesn't seem to be a way to use it with git worktree since the package cache is centralized as opposed to being at the directory/project/workspace level.

Can you elaborate on the use case? I've started putting my local package dependencies into Vendor/ submodules in the repo I'm using them. I can't use worktrees with this setup?

Re: CocoaPods trunk read-only plan

#99
post #96

Earlier quoted context omitted.

What I meant is that people who are non-ableist, non-racist, etc. do not have racism et al. popped up in their mind. Why does everything have to do with those things in people's minds? It is tiring, and I am starting to believe they are the racists. It never crossed my mind based on the name of a project. It is ridiculous.

If you’re not familiar with the experience of browsing the internet and then suddenly having deeply-held parts of your identity deemed undeserving of respect, it’s the kind of thing that the mind naturally develops habits to avoid, in much the same way that you might start to walk differently through a city after getting mugged. It is indeed tiring for everyone, but the solution is not to blame people for doing what…

Of course I do, but we are talking about a project's name.

Re: CocoaPods trunk read-only plan

#100
post #89

Earlier quoted context omitted.

We are talking about a project's name. Why did racism (and friends) came up in your mind, or an insult? Why is this the default norm, now? People are free to down-vote me, but they cannot deny there is no truth to what I am saying. I would have never thought that a project's name was intended to be racist or cause any sort of harm. Why did you?

Because it was a single word ending in -ist, the common English suffix for a prejudice or preference? There was no context indicating that it was the name of a project.

And you resort to either it being an insult or something about ableist, racism, etc.? That was not something I thought of until I got reminded.
Post reply on HN