Cargo: Minta konfirmasi data peti tertentu pada publikasi pertama

Dibuat pada 22 Nov 2020 · 3Komentar · Sumber: rust-lang/cargo

Jelaskan masalah yang Anda coba selesaikan
Permintaan dukungan paling umum yang kami dapatkan untuk crates.io adalah menghapus crates. Untuk menghindari melanggar peti/konsumen lain, kami jarang dapat memenuhi permintaan ini. Alasan umum untuk permintaan tersebut meliputi:

Saya ingin mengubah antara - dan _ , atau memodifikasi casing ( foo vs Foo ) dari peti saya.
Saya membuat kesalahan ketik. Saya sekarang telah menerbitkan dengan nama yang benar, tetapi ingin menghapus ini untuk menghindari kebingungan. (Kami menyarankan mereka mencabut semua versi peti mati.)
Saya tidak menyadari bahwa bidang penulis secara otomatis diisi dengan nama dan alamat email saya.
Saya sedang menguji sesuatu dan tidak ada yang akan menggunakan peti ini. (Mereka bisa saja mempertimbangkan untuk menggunakan pementasan, tetapi sekarang sudah terlambat.)

Jelaskan solusi yang Anda inginkan

Selama publikasi, cargo dapat memeriksa apakah peti telah diterbitkan sebelumnya. Jika ini adalah publikasi pertama, cargo akan meminta pengguna untuk mengonfirmasi berbagai metadata peti. Secara khusus, pengguna akan diminta untuk mengkonfirmasi ejaan yang tepat dari nama peti dan isi dari authors . Pengguna harus diberi tahu bahwa tidak ada cara untuk mengubah atau menghapus data ini setelah peti diterbitkan.

Setelah publikasi awal, setiap perubahan pada authors adalah perubahan eksplisit yang dilakukan pada Cargo.toml sehingga konfirmasi ini hanya perlu dilakukan sekali. Atau, prompt kepengarangan dapat dilakukan sebagai bagian dari cargo new .

Beberapa peti diterbitkan melalui CI atau skrip lainnya. Untuk menghindari pemutusan kasus penggunaan ini, pemeriksaan dan permintaan hanya boleh dilakukan pada TTY interaktif. Kami dapat menambahkan argumen gaya --yes dan memperingatkan jika argumen tersebut hilang untuk publikasi pertama non-interaktif, namun saya pikir prompt interaktif saja akan mencakup sebagian besar pengguna yang mengalami kejutan di sini.

Catatan

Kami dapat menautkan pengguna ke instruksi untuk mengonfigurasi staging registry, untuk membahas poin poin ke-4 di atas. Namun, saya pikir prioritasnya harus pada komunikasi yang jelas kepada pengguna bahwa nama peti tidak dapat diubah setelah publikasi dan mengonfirmasi bahwa mereka merasa nyaman dengan berbagi informasi kepengarangan yang dibuat secara otomatis.

Secara teoritis, pendaftar alternatif dapat memungkinkan peti diubah namanya atau dimutasi. Saya pikir ini akan mematahkan banyak asumsi di cargo dan ekosistem. Oleh karena itu saya pikir pemeriksaan ini harus berlaku untuk semua pendaftar, tetapi dapat dibuat khusus untuk crates.io jika diinginkan. (Jika kami memutuskan untuk mengarahkan pengguna ke pementasan, itu hanya boleh dilakukan untuk registri crates.io default.)

C-feature-request Command-publish

Sumber

jtgeibel

👍10 ❤3

Komentar yang paling membantu

Saya kira alternatif untuk ini adalah agar crates.io "dry run" menerbitkan peti baru secara default, dan mengirim email ke penerbit/pemilik peti untuk mengonfirmasi bahwa mereka ingin menerbitkan? Peti tidak akan ditambahkan ke indeks, mungkin, dan tidak tersedia untuk diunduh dll sampai publikasi dikonfirmasi melalui UI web (atau API, mungkin). Ini juga dapat berguna untuk, misalnya, menguji perubahan pada README atau metadata serupa lainnya tanpa memublikasikan beberapa tambalan secara berurutan.

Implementasinya tampaknya jauh lebih sulit untuk itu, jadi mungkin proposal masalah ini bisa menjadi langkah pertama.

Mark-Simulacrum pada 22 Nov 2020

👍4

Semua 3 komentar

Implementasinya tampaknya jauh lebih sulit untuk itu, jadi mungkin proposal masalah ini bisa menjadi langkah pertama.

Mark-Simulacrum pada 22 Nov 2020

👍4

Selain meminta penulis untuk mengonfirmasi detailnya, Cargo juga dapat menerapkan pemeriksaan untuk kesalahan umum dan memperingatkannya.

Peringatan: Nama peti berisi huruf besar. Nama peti karat tidak peka huruf besar-kecil dan sebagian besar peti menggunakan semua nama huruf kecil untuk konsistensi.

Peringatan: Nama peti berisi tanda hubung. Saat menggunakan peti dalam kode, tanda hubung diubah menjadi garis bawah. Menggunakan tanda hubung dalam nama peti menghasilkan peti yang memiliki nama berbeda di crates.io daripada di kode.

dll.

Rantanen pada 22 Nov 2020

terbitkan "dry run"

Ini mengingatkan saya pada permintaan fitur menarik rust-lang/crates.io#1515 yang akan menyenangkan untuk dimiliki.

Peti tidak akan ditambahkan ke indeks, mungkin, dan tidak tersedia untuk diunduh dll sampai publikasi dikonfirmasi melalui UI web (atau API, mungkin).

Saya tidak berpikir kami memiliki masalah terbuka untuk ini, tetapi di suatu tempat saya melihat saran bahwa crates.io dapat mengizinkan reservasi nama peti dengan waktu terbatas (dengan kemampuan untuk menyegarkannya secara manual setiap beberapa bulan). Jika kami memiliki infrastruktur untuk mencadangkan nama, maka casing khusus yang diterbitkan pertama dapat dibangun di atas itu. Kami ingin peti yang dipesan muncul dalam pencarian dan memiliki semacam halaman arahan yang mengatakan bahwa peti sudah dipesan atau tertunda. (Dan nama yang dicadangkan dapat diubah dengan cara yang kompatibel hingga versi pertama adalah

Ini juga dapat berguna untuk, misalnya, menguji perubahan pada README atau metadata serupa lainnya tanpa memublikasikan beberapa tambalan secara berurutan.

Saya sangat menyukai ide ini, karena saya pasti memiliki beberapa rilis yang dibuat beberapa menit setelah melihat rilis baru saya yang mengkilap memiliki masalah dengan README. Ini melampaui --dry-run[=verify] dan pendekatan publikasi pertama di atas. Pengguna dapat memublikasikan dengan --dry-run=pending dan kami akan menampilkan versi sebagai tertunda (mirip dengan yanked ) tetapi hanya pemilik peti yang dapat melihat versi yang tertunda. Khusus untuk README, masalah terbesar yang saya lihat adalah bahwa mereka dapat di-cache (saya pikir untuk 1 hari saat ini) ketika disajikan dari S3. Jadi kita mungkin perlu hal-hal kasus khusus untuk versi tertunda.

Saya pikir fitur-fitur ini dapat bekerja sama dengan baik dan menyediakan jalur yang baik untuk perubahan bertahap. Saya juga setuju bahwa casing khusus pada sisi server publikasi pertama saat ini akan membutuhkan banyak pekerjaan. Saya akan tertarik untuk melihat semua opsi ini dieksplorasi lebih lanjut.

jtgeibel pada 25 Nov 2020

Apakah halaman ini membantu?

0 / 5 - 0 peringkat