Carthage: Tambahkan dukungan untuk "subspecs"

Dibuat pada 27 Jun 2015 · 4Komentar · Sumber: Carthage/Carthage

Hai teman-teman,
Saya pikir akan sangat luar biasa jika Carthage dapat menambahkan dukungan untuk sesuatu yang mirip dengan subspesifikasi CocoaPods. Ini akan mendorong pengembang untuk membangun ekstensi dan kategori pada kerangka kerja mereka yang menambahkan dukungan untuk beberapa kerangka kerja paling populer saat ini.

Saya pikir ini mungkin hari ini dengan menandai cabang atau komit yang menambahkan ekstensi tertentu ke kerangka kerja, tetapi saya pikir itu bisa menambah banyak kerumitan untuk mendorong rilis, terutama ketika versi baru Swift dirilis, atau permintaan tarik adalah diajukan.

Koreksi saya jika saya salah, tetapi saya pikir ini akan menjadi hal yang baik untuk ditangani oleh infra.

Pikiran?

Sumber

justinmakaila

Komentar yang paling membantu

Tidak, maaf. Ini mendorong kerangka kerja besar, yang bertentangan dengan modularitas dan kemampuan menyusun.

Saya lebih suka Carthage untuk mendorong kerangka kerja yang lebih kecil yang dapat digunakan secara independen satu sama lain.

jspahrsummers pada 27 Jun 2015

👎3 👍2

Semua 4 komentar

Ini berpotensi diimplementasikan dengan pengaturan target di xcodeproj , atau bahkan binari yang didistribusikan melalui Carthage .

justinmakaila pada 27 Jun 2015

Tidak, maaf. Ini mendorong kerangka kerja besar, yang bertentangan dengan modularitas dan kemampuan menyusun.

Saya lebih suka Carthage untuk mendorong kerangka kerja yang lebih kecil yang dapat digunakan secara independen satu sama lain.

jspahrsummers pada 27 Jun 2015

👎3 👍2

Saya juga berpikir bahwa ini adalah sesuatu yang harus dipertimbangkan untuk Carthage.

Banyak proyek misalnya memiliki ReactiveCocoa sebagai dependensi lunak untuk menambahkan dukungan ReactiveCocoa.
Saat ini, ada dua opsi dalam kasus ini:

Tambahkan dukungan ReactiveCocoa dalam proyek terpisah
Sertakan ReactiveCocoa secara default (memaksa ketergantungan ke pengembang lain)

Saya pikir @jspahrsummers lebih suka cara sebelumnya untuk membuat kerangka kerja kecil opsional yang misalnya menambahkan dukungan ReactiveCocoa, yang memaksa proyek menjadi lebih seperti Frameworks (_yay_!).

Pendekatan lain adalah membuat proyek mengekspos beberapa .framework yang saling bergantung satu sama lain.
Misalnya

X.framework (mandiri)
XReactiveCocoaExtensions.framework (menautkan ke X.framework dan ReactiveCocoa.framework)

Saya baru saja menguji ini dengan cepat, tetapi bagi saya pendekatan ini terlihat sangat menjanjikan. Dengan cara ini, kita masih dapat memiliki satu proyek yang mengekspos banyak kerangka kerja. Pengembang yang tidak ingin menggunakan ReactiveCocoaExtensions cukup mengabaikan XReactiveCocoaExtensions.framework yang dibangun dan siap digunakan.

Adakah pemikiran atau peringatan terhadap metode ini?

aschuch pada 29 Jun 2015

@aschuch Saya setuju dengan apa yang Anda katakan. Saya mengalami masalah ini dengan Moya. Saat ini, carthage build Moya bergantung pada ReactiveCocoa hanya untuk ReactiveMoyaProvider , yang mungkin atau mungkin tidak diimplementasikan oleh pengguna akhir.

Saya sedang dalam proses refactoring garpu saya sendiri untuk itu, di mana dependensi yang berbeda disertakan dan dikelola di cabang yang terpisah (Moya, ReactiveMoya, dan RxMoya). Ini memiliki beberapa implikasi pemeliharaan yang cukup serius, dan batasan untuk kerangka kerja yang mungkin ingin mengekspos antarmuka untuk pola pengembangan tertentu.

justinmakaila pada 29 Jun 2015

Apakah halaman ini membantu?

0 / 5 - 0 peringkat