You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cocoapods recently released a 1.12 update that includes a relaxation on the activesupport requirement from < 7 to < 8. The version update was needed for licensed to be able to integrate with cocoapods, however with that work done I'm concerned that the versioning is going to cause issues again in the future.
Instead of keeping the integration that exists with cocoapods, I think a better solution is to create a cocoapods plugin similar to https://github.com/segiddins/cocoapods-dependencies that can be used by licensed. That plugin doesn't look like a good fit for licensed usage because for basic pod dependencies usage it seems to just print the podfile.lock entries without any additional data like targets or path to the root pod folder.
The plugin could expose a new CLI command that would be used by licensed, more or less pulling the code from Cocoapods#enumerate_dependency into a separate gem. The plugin would output the resulting name, path, and version data to the CLI in an easily parseable format like JSON or YAML or similar.
sequenceDiagram
participant L as licensed
participant P as Cocoapods plugin
L ->> P: call plugin CLI, e.g. `pod dependencies list --targets ...`
P ->> P: enumerate dependency information
P ->> L: JSON (or similar) formatted list of dependencies
Loading
This approach offers a few benefits:
It decouples cocoapods dependency requirements from licensed's dependency requirements, resolving any concerns about this problem in the future.
It removes any concern about bloating licensed's installation size from the full cocoapods gem
It makes the functionality usable for other enumeration tools
When implementing the support of cocoapods into licensed the activesupport dependency requirements and the conflicts that could emerge is not something I thought about.
Just like you, I think the the most important thing for licensed is it's stability. So investing time to make the cocoapods integration less prone to requirements failure is a great idea
I've created the plugin here but haven't yet published it. I'll make sure the integration with licensed works well before writing a README and releasing the plugin to rubygems
Cocoapods recently released a 1.12 update that includes a relaxation on the activesupport requirement from
< 7
to< 8
. The version update was needed for licensed to be able to integrate with cocoapods, however with that work done I'm concerned that the versioning is going to cause issues again in the future.Instead of keeping the integration that exists with cocoapods, I think a better solution is to create a cocoapods plugin similar to https://github.com/segiddins/cocoapods-dependencies that can be used by licensed. That plugin doesn't look like a good fit for licensed usage because for basic
pod dependencies
usage it seems to just print the podfile.lock entries without any additional data like targets or path to the root pod folder.The plugin could expose a new CLI command that would be used by licensed, more or less pulling the code from Cocoapods#enumerate_dependency into a separate gem. The plugin would output the resulting name, path, and version data to the CLI in an easily parseable format like JSON or YAML or similar.
This approach offers a few benefits:
cc @LouisBoudreau does this seem reasonable?
The text was updated successfully, but these errors were encountered: