Cargo: Perilaku baru kombinasi `--feature` + `--package`

https://github.com/rust-lang/cargo/issues/5362 menurut saya adalah manifestasi dari perilaku aneh yang lama.

Pengumuman di irlo: https://internals.rust-lang.org/t/help-us-test-the-breaking-bug-fix-to-cargo-features/7317

Saya pikir https://github.com/rust-lang/cargo/issues/4942 juga merupakan masalah ini.

Dan https://github.com/rust-lang/cargo/issues/4753 juga

(salah ketik dalam deskripsi masalah: --pacakge )

Sayangnya ini merusak Servo , jadi kami mungkin perlu mendukung ini, setidaknya dalam bentuk agresif yang maksimal ini.

Namun, saya ingin tahu apa yang akan kami lakukan dengan masalah pemilihan fitur secara umum?

Saya berasumsi bahwa pada akhirnya kami ingin memperbaiki masalah utama dengan fitur. Saat ini, fitur bersifat global per kompilasi, dan itu berarti fitur-fitur tersebut berpindah dari dev-deps ke deps normal dan cargo build -p foo dan cargo build -p foo -p bar membangun paket foo berbeda .

Memperbaiki itu , bagaimanapun, akan menjadi perubahan besar: tiba-tiba, Cargo akan memilih serangkaian fitur yang lebih kecil :-(

Namun, jika kita memperbaikinya, maka perilaku kombinasi --package dan --features juga perlu diubah. Dengan kata lain, PR ini adalah semacam bagian dari masalah yang lebih besar itu.

Pertanyaan inti menurut saya adalah apakah kita merasa nyaman dengan akhirnya mengubah serangkaian fitur yang diaktifkan? Jika ya, maka saya pikir kita dapat memodifikasi perbaikan saat ini agar tidak benar-benar error-out, tetapi untuk mengabaikan argumen fitur untuk beberapa paket, mencetak peringatan seperti "ini diterima di versi Cargo sebelumnya dan mengaktifkan fitur dengan cara yang mengejutkan, dan bukan diabaikan".

$ kargo +tes stabil --semua --fitur xyz

Dulunya bekerja. Dan harapannya adalah "Aktifkan rangkaian masa depan yang ditentukan untuk peti yang mendukungnya".

$ kargo +tes malam --semua --fitur xyz
kesalahan: tidak dapat menentukan fitur untuk lebih dari satu paket

Sekarang kita melihat ini (terima kasih kepada CI untuk menangkapnya segera dan tidak setelah rilis Rust) dan tidak masalah apakah semua anggota ruang kerja memiliki xyz atau tidak, kesalahannya sama.

Mengapa masalah asli ( cargo --package foo --feature feat ) memengaruhi build tanpa --package ? #5390 bukanlah ide yang baik tanpa penjelasan kompatibilitas (apa itu? bagaimana cara memperbaiki kesalahan mistis itu? bagaimana cara kerjanya di masa depan?). Kesalahan itu harus berisi setidaknya nomor masalah (karena ini adalah masa depan yang rusak dan tetap ada di malam hari (yaitu tidak stabil).

Dan harapannya adalah "Aktifkan rangkaian masa depan yang ditentukan untuk peti yang mendukungnya".

Bukan berarti harapan ini salah. Apa yang sebenarnya terjadi adalah bahwa fitur tersebut diaktifkan hanya untuk paket di direktori kerja saat ini. Dengan kata lain, tidak relevan apakah semua anggota memiliki fitur xyz , karena ini hanya berlaku untuk satu anggota, dan bukan yang ditentukan melalui argumen -p .

Kesalahan itu pasti mengandung setidaknya nomor masalah

Itu pasti kelalaian saya :(

Berikut adalah contoh kecil yang menunjukkan perbedaan perilaku: https://github.com/matklad/features-behavior

telah memengaruhi build tanpa --package?

--all adalah singkatan untuk --package member1 --package member2 --package member3 dll, dan mengalami masalah yang sama: flag --feature tidak berlaku untuk paket yang dipilih. Saya telah memperluas contoh di https://github.com/matklad/features-behavior untuk menunjukkan bagaimana ini memengaruhi --all .

Melanggar perubahan pada fungsionalitas yang stabil tidak dapat diterima. Harap kembali dan temukan cara untuk membuat keikutsertaan ini.

Betapapun aneh dan subjektifnya perilaku lama yang rusak, sudah ada lebih dari cukup lama sehingga banyak proyek besar telah membangun solusi yang mengandalkannya. Sangat mudah untuk mengatakan ini di belakang, tapi saya pikir seharusnya tidak mengejutkan bahwa perubahan seperti ini pasti akan merusak beberapa build.

https://github.com/rust-lang/cargo/pull/5390 , PR yang mengaktifkan perubahan ini secara default, mengatakan:

Sejauh ini, umpan balik di https://internals.rust-lang.org/t/help-us-test-the-breaking-bug-fix-to-cargo-features/7317 positif

Pada saat penulisan itu, utas forum itu berumur 2 hari dan mendapat tanggapan dari tiga orang, salah satunya mengatakan bahwa bangunan mereka rusak. Bagaimana ini cukup "positif"?

Tetapi bahkan jika diskusi itu telah mendapat perhatian masyarakat luas, kerusakan seperti ini tanpa keikutsertaan masih merupakan IMO yang tidak dapat diterima. Proyek yang paling mungkin terpengaruh adalah proyek dengan sistem pembangunan kompleks yang melibatkan banyak peti. Mereka mungkin atau mungkin tidak terlibat dalam pengembangan Rust and Cargo sehari-hari.

Sekarang jika kita akan membuat perubahan di sekitar pemilihan fitur, selain menjadi opt-in (mungkin melalui edition = "2018" dalam peti root atau ruang kerja?) Saya pikir kita harus menghabiskan lebih banyak waktu dan melibatkan lebih banyak orang untuk mempertimbangkan apa yang seharusnya menjadi perilaku baru. Secara khusus, memperbaiki https://github.com/rust-lang/cargo/issues/4463. Dan mungkin memisahkan gagasan "Memilih yang mana dari beberapa artefak 'root' di ruang kerja (masing-masing dengan grafik ketergantungan dan pemilihan fitur)" dan "Memilih subset dari satu grafik ketergantungan".

Karena bug kargo ini stdsimd diam-diam tidak menguji beberapa kombinasi fitur (https://github.com/rust-lang-nursery/stdsimd/pull/569). Bahwa ini tidak menghasilkan peringatan apa pun membuatku khawatir.

Melanggar perubahan pada fungsionalitas yang stabil tidak dapat diterima.

Ini tidak benar. Melanggar perubahan pada fungsionalitas stabil dapat diterima jika fungsionalitasnya rusak , jika tidak, kami tidak akan pernah dapat memperbaiki bug apa pun jika perilaku perbaikan dapat diamati oleh peti saat ini.

Pertanyaan yang harus kita selesaikan di sini adalah apakah fungsi ini rusak atau tidak. Jika tidak rusak, Anda benar karena kami tidak dapat memperbaikinya. Tapi jika rusak, kita bisa memperbaikinya. Bergantung pada dampak perbaikan, kami mungkin harus memperingatkan terlebih dahulu untuk waktu yang cukup lama sebelum menerapkan perbaikan, tetapi perbaikan itu mungkin dan tidak memerlukan edisi baru, meskipun kami dapat menggunakannya untuk menerapkan perbaikan.

Saat ini, ketika saya memiliki ruang kerja dengan paket foo dengan fitur bar , mengeksekusi:

cargo test --features=bar -p foo

mengkompilasi foo tanpa fitur bar . Saya pribadi berpikir perilaku ini rusak, dan mereka yang menginginkan perilaku ini harus menulis cargo test -p foo tanpa --features=bar .

Kami dapat membagi rambut tentang detail yang lebih baik apa arti janji stabilitas, tetapi dalam kasus khusus ini jelas bahwa sejumlah proyek telah terkena dampak negatif oleh perubahan ini sampai dikembalikan, tanpa jalur migrasi yang jelas.

memperingatkan terlebih dahulu untuk waktu yang cukup lama

Saya tidak berpikir itu cukup baik. Perubahan penting ini perlu ikut serta, baik dengan saluran khusus di manifes ruang kerja atau sebagai bagian dari sakelar edisi.

tetapi dalam kasus khusus ini jelas bahwa sejumlah proyek telah terkena dampak negatif

Setelah melalui ini dan masalah terkait, termasuk servo, satu-satunya hal yang jelas bagi saya adalah bahwa perubahan ini telah merusak pembangunan beberapa proyek. Fakta bahwa proyek-proyek ini telah terkena dampak negatif oleh perubahan ini sama sekali tidak jelas bagi saya, karena saya belum menemukan banyak informasi tentang mengapa sebenarnya pembangunan itu rusak untuk proyek-proyek itu dan apakah perilaku sebelumnya benar-benar dimaksudkan.

FWIW perubahan ini akan merusak build stdsimd juga, dan dengan melakukan itu akan menemukan bug di CI stdsimd yang telah lama kami perbaiki. Oleh karena itu, stdsimd akan terpengaruh secara positif oleh perubahan ini, bahkan jika perubahan tersebut memerlukan beberapa upaya dari pihak kami untuk memperbaikinya.

Hanya untuk tidak mencampuradukkan hal-hal:

• "Perilaku baru" yang disebutkan dalam judul edisi ini adalah yang diaktifkan di https://github.com/rust-lang/cargo/pull/5353 dan dikembalikan di https://github.com/rust-lang/cargo/pull /5430.
• "Perilaku saat ini" adalah yang telah ada selama ruang kerja dan flag fitur telah ada, dan sama di Stable dan Nightly hari ini.

Melanggar build dengan cara yang tidak terkait dengan fitur yang tidak stabil adalah dampak negatifnya. Saya tidak ingat detailnya pada saat ini, tetapi kami telah menemukan solusi untuk keanehan perilaku saat ini, dan dalam menerapkan solusi tersebut bergantung pada perilaku saat ini.

Perilaku baru hadir di Nightly selama sekitar dua minggu (antara https://github.com/rust-lang/rust/pull/49939 dan https://github.com/rust-lang/rust/pull/50344). Saya tidak tahu mengapa bug stdsimd tidak ditemukan selama waktu itu. Untuk Servo kami memiliki pekerjaan Travis-CI harian yang menimpa file rust-toolchain disematkan di repo dan mencoba membangun dengan Nightly terbaru, memberi tahu beberapa orang jika itu gagal.

Saya tidak berpikir itu cukup baik. Perubahan kepentingan ini perlu ikut serta

Saya rasa status quo juga tidak cukup baik; bug ini seharusnya sudah diperbaiki sejak lama. Tapi saya setuju bahwa #5353 mungkin bukan solusi ideal.

kesalahan: tidak dapat menentukan fitur untuk lebih dari satu paket

Bendera --feature mempengaruhi paket yang dipilih. Ini adalah kesalahan untuk
tentukan --feature dengan lebih dari satu -p , atau dengan -p luar
ruang kerja (yang terakhir bisa bekerja secara teori, tetapi akan sulit untuk
melaksanakan).

Ini jelas merupakan masalah, karena orang telah menggunakan ekspresi seperti cargo test --all --features foo berulang kali. Tapi itu sendiri merupakan masalah karena ekspresi tidak melakukan apa yang diharapkan banyak orang.

Dan harapannya adalah "Aktifkan rangkaian masa depan yang ditentukan untuk peti yang mendukungnya".

Bukan berarti harapan ini salah. Yang sebenarnya terjadi adalah...

Harapan ini bisa kita wujudkan. Di sisi positifnya, itu hanya akan merusak tes jika tes tersebut sebenarnya menguji kode yang rusak. Di sisi negatifnya, kesalahan ketik atau lupa menambahkan fitur ke sub-paket bisa luput dari perhatian.

Tetapi kompromi yang masuk akal adalah mengaktifkan fitur yang ditentukan oleh --feature untuk semua paket yang dipilih, tetapi juga menambahkan opsi --allow-missing-feature yang secara diam-diam mengabaikan fitur pada paket tanpanya.

Ringkasan: perbaikan yang tepat mungkin akan menyebabkan beberapa kerusakan pada sistem build yang ada. Tapi itu harus mengoreksi mis-konsepsi dan harus sangat mudah bagi pengguna untuk memperbaikinya.

IMHO perlu menderita beberapa kerusakan di sini. Perhatikan juga bahwa kerusakan sebagian besar hanya akan memengaruhi pengujian integrasi berkelanjutan, dan bukan pengguna yang membangun/menguji paket secara manual dan bergantung padanya secara transitif.

perbaikan yang tepat mungkin akan menyebabkan beberapa kerusakan […] IMHO, ada baiknya menderita beberapa kerusakan di sini.

Kerusakan dan perbaikan vs keduanya bukan satu-satunya pilihan! Kita dapat memiliki konfigurasi di root ruang kerja Cargo.toml untuk membuat keikutsertaan perubahan perilaku.

Perhatikan juga bahwa kerusakan sebagian besar hanya akan memengaruhi pengujian integrasi berkelanjutan, dan bukan pengguna yang membangun/menguji paket secara manual dan bergantung padanya secara transitif.

IIRC ini tidak terjadi dengan Servo, kami bisa membangun sama sekali. Saya tidak yakin mengapa Anda membuat perbedaan ini, CI dirancang sedekat mungkin dengan penggunaan lain.

Kami berada di jalan buntu di sini.

Jika kami membuat perubahan ini keikutsertaan, kami tidak merusak kode apa pun di alam liar. Ini bagus karena tidak merusak kode di alam liar yang berfungsi dengan benar sebagaimana dimaksud. Pada saat yang sama, ini buruk karena ada kode di alam liar yang diam-diam rusak, dan perubahan ini tidak memperbaikinya atau memperingatkan pengelola kode ini bahwa itu perlu diperbaiki. Jika kami melakukan penyisihan ini, kami memecahkan kode yang rusak, yang baik, tetapi kami juga memecahkan kode yang benar, yang buruk.

Sejujurnya, kami di sini karena perilaku saat ini terlalu implisit, orang yang berbeda mengharapkannya untuk berperilaku berbeda, dan hal-hal yang terjadi secara diam-diam bekerja untuk semua orang, menghasilkan kode yang benar dan salah.

Solusi kompromi untuk masalah ini mungkin hanya dengan memperbaiki implisitnya. Kami hanya dapat menambahkan dua flag, yang mengaktifkan perilaku yang berbeda, dan mulai memperingatkan bahwa semua proyek harus secara eksplisit menentukan perilaku mana yang mereka inginkan (bagaimana tepatnya sesuatu yang dapat kami putuskan nanti). Itu akan lebih baik daripada yang kita miliki saat ini, itu tidak merusak kode apa pun, dan itu membuat orang dengan kode yang rusak tahu bahwa kode mereka mungkin rusak.

Apakah kita pernah mengubah peringatan ini menjadi kesalahan atau tidak, dan bagaimana kita akan melakukannya, adalah bagian paling kontroversial dari masalah ini, dan sesuatu yang sebenarnya tidak perlu kita diskusikan sekarang.

Lalu saya berasumsi salah tentang Servo ... mengapa Anda menggunakan --package dengan banyak paket untuk alasan lain selain pengujian? Apakah ini mudah diubah untuk mengurangi kerusakan yang disebabkan oleh #5353? Saya mencoba mengikuti tautan di atas tetapi tidak menemukan banyak informasi.

Kita dapat memiliki konfigurasi di root Cargo.toml ruang kerja untuk membuat keikutsertaan perubahan perilaku.

IMO ini adalah solusi jelek — banyak pengguna akan lupa atau tidak tahu tentang ini, kemudian terkejut ketika di jalan mereka menemukan thing tidak bekerja dengan fitur foo meskipun cargo test --package thing --feature foo berada di CI mereka.

Konfigurasi dan penggunaan kargo sudah rumit dengan dokumentasi penting yang perlu dibaca pengguna untuk memahami berbagai fitur. Menambahkan opsi konfigurasi lebih lanjut seharusnya tidak menjadi opsi yang disukai IMO.

Solusi kompromi ... Kami hanya bisa menambahkan dua bendera

Setidaknya ini tidak secara implisit melakukan hal yang salah untuk siapa pun, dan jika itu hanya muncul saat menggunakan --feature dengan --package / --all maka itu tidak memengaruhi orang lain . Dapat diterima, tetapi saya masih lebih suka bahwa ini hanya "diperbaiki" untuk semua orang (dengan solusi mudah bagi mereka yang terpengaruh).

Oke, itu sangat membuat frustrasi bahwa menggabungkan --package dengan --features benar-benar rusak dan tidak menghasilkan peringatan atau kesalahan sama sekali. Siapa pun yang berasumsi bahwa kargo menerapkan perilaku yang diharapkan secara wajar di sini akan melihat tes fitur CI lulus tanpa masalah, tidak memiliki indikasi bahwa peti hanya sedang dibangun tanpa fitur diaktifkan.

Sangat frustasi melihat ada perbaikan yang dibuat dan kemudian tiba-tiba dikembalikan, tanpa mitigasi atau kemajuan lain sejak itu. Ini tampaknya menjadi pijakan yang cukup jelas di mana sebagian besar kasus tampaknya adalah orang yang menggunakan --all atau -p X dan tidak menyadari interaksi/implikasi, dengan bagian-bagian kode secara diam-diam tidak dibangun atau diuji. Itu berfungsi ketika peti root memiliki feature = ["child_crate/feature"] . Tanpa peti root, menggunakan --features mungkin harus error untuk menunjukkan itu rusak (#5849) atau gunakan saja perilaku tetap.

Melanggar build dengan cara yang tidak terkait dengan fitur yang tidak stabil adalah dampak negatifnya. Saya tidak ingat detailnya pada saat ini, tetapi kami telah menemukan solusi untuk keanehan perilaku saat ini, dan dalam menerapkan solusi tersebut bergantung pada perilaku saat ini.

Mengandalkan perilaku yang jelas rusak dan aneh, menganggapnya sebagai solusi dalam skrip build, tidak menggunakan solusi lain yang mengandalkan perilaku wajar yang lebih mapan (seperti mengubah CWD daripada menggunakan -p/--all), dan tidak pernah mengharapkannya tetap tampaknya agak tidak masuk akal? Ada solusi yang dapat digunakan untuk menyebabkan lebih sedikit kerusakan atau bahkan sebagian atau sepenuhnya kompatibel dengan perilaku lama, tetapi tampaknya tidak jelas dari masalah ini dan diskusi seputar mengapa atau bagaimana perilaku lama diandalkan sejak awal.

@arcnmx melanggar perubahan, apakah itu memperbaiki bug atau tidak, berhati-hatilah saat mendekat. Kami tidak dapat menerapkan perubahan ini dan kemudian mengatakan "Anda semua berurusan dengan kejatuhannya, ini adalah perubahan yang lebih baik". Kebijakan kami adalah bahwa kami akan meluncurkan perubahan ini secara perlahan, memberikan peringatan dan semacamnya di sepanjang jalan. Misalnya kita perlu:

• Tambahkan sakelar konfigurasi untuk mengaktifkan perilaku baru
• Tambahkan peringatan hari ini ketika perilaku baru dan perilaku saat ini berbeda
• Dorong ke ekosistem, evaluasi dampak
• Akhirnya, ketika sudah siap, ubah defaultnya.

Ini membutuhkan banyak pekerjaan dan tidak ada yang cukup termotivasi untuk mendorongnya sampai selesai.

Maaf jika ini sudah dibahas sebelumnya, tetapi apakah mungkin membuat perubahan ini untuk ruang kerja virtual secara khusus? Dalam hal ini, tidak ada paket saat ini, jadi sepertinya kecil kemungkinannya untuk menghancurkan dunia.

Ya, niat saya adalah untuk menghidupkan kembali diskusi di sini dan menentukan langkah-langkah perantara dan rencana migrasi apa yang mungkin, hanya cukup membuat frustrasi bahwa perilaku yang tepat tidak dapat diakses terjebak di balik bendera yang tidak stabil/malam. Poin utama yang menjadi perhatian saya adalah:

1. Mempertimbangkan bahwa ruang kerja virtual benar-benar rusak sepengetahuan saya ketika dikombinasikan dengan flag fitur, langsung mengaktifkan perilaku yang diharapkan/diperbaiki akan ada cara yang baik untuk mengatasi #5849. Kalau tidak, itu benar-benar harus kesalahan langsung untuk mencegah kebingungan oleh jaminan palsu saat ini bahwa semuanya baik-baik saja.
   
   
   
   • selama ada kesepakatan bahwa perilaku baru itu benar (mengingat PR asli telah disetujui, mungkin)
   
   
2. Mengidentifikasi mengapa perubahan merusak banyak hal, karena saya tidak dapat menemukan penjelasan tentang bagaimana dan mengapa perilaku yang rusak saat ini diandalkan oleh proyek yang ada. Sebagian besar protes tampaknya tidak mengartikulasikan mengapa pengembalian itu diperlukan, dan...
   
   
   
   • apakah ada pendekatan yang lebih konservatif atau kompatibel ke belakang yang dapat digunakan di sini?
   
   
   • jika tidak / terlepas dari hal di atas, melanjutkan dengan rencana siklus peringatan konfigurasi/bendera seperti itu cukup masuk akal, dengan beberapa kesepakatan tentang pendekatan kasar untuk diikuti
   
   

Mungkin mengganti default (yaitu gagal keras daripada hanya memperingatkan) juga dapat memiliki opsi "memilih kembali" (disebutkan dalam pesan kesalahan) untuk build yang perlu beberapa detik sebelum bermigrasi. _Kemudian_ kita dapat membatalkan opsi opt-back.

Mengingat dampak yang kami alami sebelumnya, saya akan berhati-hati untuk mengubah ini bahkan untuk ruang kerja virtual sendiri. Saya pribadi lebih suka kita mengambil rute konservatif "peringatkan jika ada yang berbeda, izinkan konfigurasi untuk perilaku baru, 'benar'"

Hai, pengembang dasar menggunakan karat dan membahas masalah ini di sini. Saya setuju dengan proposal untuk mengubah perilaku dan saya memahami kekhawatiran tentang stabilitas perilaku saat ini namun bermasalah.

Mengingat dampak yang kami alami sebelumnya, saya akan berhati-hati untuk mengubah ini bahkan untuk ruang kerja virtual sendiri. Saya pribadi lebih suka kita mengambil rute konservatif "peringatkan jika ada yang berbeda, izinkan konfigurasi untuk perilaku baru, 'benar'"

Proposal ini akan baik-baik saja untuk saya: Ketika melakukan cargo build -p foo --feature bar di tingkat ruang kerja, saya harus mendapatkan peringatan yang memberi tahu saya bahwa saya menggunakan fitur di tingkat ruang kerja yang tidak seperti yang saya harapkan. Seharusnya disarankan untuk menggunakan opsi .cargo/config atau baris perintah untuk ikut serta dalam perilaku "tetap" alami.

Bersulang.

Solusi alternatif: hentikan opsi --package dan --all . Untuk lebih jelasnya: Saya tidak menganggap ini sebagai solusi yang baik , tetapi jika kombinasi --feature dan --package tidak dapat diperbaiki, ini adalah alternatif.

Kami sudah memiliki cara lain untuk menguji sub-paket:

cargo test --manifest-path rand_core/Cargo.toml --no-default-features --features=alloc

@dhardy Terima kasih banyak telah menunjukkan solusi yang efektif dan tidak jelas ini untuk masalah ini!

Karena https://github.com/rust-lang/cargo/issues/5932 solusi itu tidak akan berfungsi di semua kasus, tetapi harus berfungsi untuk ruang kerja apa pun yang tidak menggunakan default-members .

Apakah solusi @dhardy dapat menggunakan kembali direktori target ruang kerja, dan menyelesaikan ke versi dependensi yang sama seperti saat membangun peti root?

... sejujurnya, baik semantik saat ini maupun yang diusulkan tidak terdengar tepat bagi saya. Inilah yang saya ingin --all --no-default-features --features blah,blip lakukan:

• Terapkan semua opsi fitur (dalam hal ini, --all --no-default-features --features blah,blip ) ke paket root.
• Selesaikan kumpulan fitur yang akan diaktifkan untuk setiap subkrat seolah-olah kita sedang membangun paket root.

Bagaimanapun, peti di ruang kerja sudah memiliki tanggung jawab untuk mengontrol fitur satu sama lain (misalnya hampir semua dependensi pada peti internal atau "detail implementasi" harus menggunakan default-features = false ). Dan dengan cara ini, cargo test --all akan membangun setiap peti dengan cara yang persis sama seperti yang dilakukan cargo test , kecuali ia juga akan membangun dan menjalankan kasus uji untuk anggota ruang kerja.

@ExpHP kita berbicara tentang ruang kerja di sini. Apa yang Anda maksud dengan "paket root"?

Maksud saya yang Cargo.toml-nya berisi tabel workspace , dan dependensi jalurnya menentukan anggota ruang kerja.

Untuk ruang kerja tanpa paket root yang mengandalkan tabel [members] eksplisit, saya tidak yakin apakah --all dengan fitur masuk akal. Saya kira perilaku yang diusulkan mungkin masuk akal di sini (meskipun rasanya seperti bebek-mengetik) ... tapi saya juga merasa bahwa ruang kerja tersebut akan mendapat manfaat dari memiliki sebuah paket akar untuk bertindak sebagai otoritas pada fitur apa artinya ketika kargo digunakan dalam direktori root ruang kerja.

Klarifikasi: ketika saya mengatakan "perilaku yang diusulkan" saya merujuk pada gagasan di mana flag fitur diterapkan ke semua peti (dan diabaikan pada peti yang tidak memilikinya) untuk --all . Saya pikir saya sedang memikirkan masalah lain dan menjadi bingung tentang di mana saya setelah mengikuti tautan balik X_X

Saya tidak yakin apakah --all dengan fitur masuk akal.

Saya pikir Anda harus dapat menentukan package/feature sebagai fitur dalam kasus itu.

Saya tidak yakin apakah --all dengan fitur masuk akal.

Saya pikir Anda harus dapat menentukan package/feature sebagai fitur dalam kasus itu.

Saya akan menggunakan sesuatu seperti itu untuk hal-hal yang ingin saya aktifkan di profil yang berbeda, yaitu

cargo test --all --features testing

untuk mengaktifkan fitur tertentu saat pengujian tetapi tidak dalam mode rilis atau pengembangan. Atau lebih baik lagi, jika kargo dapat mendukung bendera fitur di bagian profilnya, itu akan lebih baik.

Bagi saya, itu akan cukup untuk memiliki sesuatu seperti:

cargo build -C subcrate --features ...

Yang berperilaku seperti:

cd subcrate
cargo build --features ...
cd ..

cargo build --features ... --manifest-path subcrate/Cargo.toml .

Saya membuat proposal untuk mengubah perilaku -Zpackage-features di #8074. Saya akan menghargai umpan balik dari siapa pun yang mengikuti masalah ini.

Tujuannya adalah untuk mencakup lebih banyak kasus penggunaan yang diminati orang, dan untuk mendorong ini menuju stabilisasi. Perilaku baru diringkas dalam dokumen . Dibandingkan dengan perilaku -Zpackage-features , ini berubah:

• Anda dapat menentukan fitur untuk beberapa paket sekaligus. Tidak semua paket perlu mendefinisikan setiap fitur, Cargo hanya mengaktifkan fitur yang cocok.
• Menambahkan sintaks --features member_name/feature_name untuk mengatur fitur pada anggota tertentu.

Saya pikir dimungkinkan untuk menstabilkan perilaku baru apa adanya kecuali untuk satu perubahan yang tidak kompatibel dari -p foo --features … di dalam direktori anggota. Saya tidak dapat memikirkan rencana transisi yang baik untuk itu, jadi saya pikir solusinya adalah dengan membuat keikutsertaan perilaku baru. Kami sedang merencanakan mekanisme keikutsertaan untuk penyelesai fitur baru, jadi saya pikir itu bisa saja menggunakan opsi yang sama (mungkin bendera yang ditentukan dalam definisi [workspace] ).

@ehuss Saya sangat menyukai proposal itu!