Cargo: Jadikan `kargo ketinggalan zaman` sebagai bagian dari kargo itu sendiri

Saya yakin ada banyak contoh di mana ini dapat membantu. Inilah salah satu yang menginspirasi saya untuk menulis proposal ini: https://github.com/servo/unicode-bidi/issues/46#issuecomment -316778436

/cc @alexcrichton , @Manisharth , @anowell

Saya pikir kita mungkin ingin mengetahui apa yang dilakukan manajer paket lain di sini, misalnya apakah npm, yarn, bundler, rubygems, pip, dll melakukan hal seperti ini? Saya pribadi mendapat kesan bahwa kekhawatiran semacam ini biasanya diarahkan ke layanan pihak ketiga.

Berikut ringkasan fitur serupa di beberapa pengelola paket lainnya.

JS NPM

NPM CLI memiliki subperintah outdated bawaan yang menunjukkan status paket yang tidak cocok dengan versi saat ini , yang diinginkan , dan terbaru .

Seperti cargo update , npm update memperbarui versi saat ini menjadi want , jika diperlukan dan memungkinkan.

Sepertinya npm update tidak memiliki fungsi lagi di area ini. Juga, tidak ada sub-perintah lain yang terlihat terkait.

Referensi: https://docs.npmjs.com/cli/outdated

Keterangan

(dari https://github.com/npm/npm/blob/latest/doc/cli/npm-outdated.md )

Perintah ini akan memeriksa registri untuk melihat apakah ada (atau, spesifik) paket yang diinstal saat ini kedaluwarsa.

Dalam keluaran:

• wanted adalah versi maksimum dari paket yang memenuhi kisaran semver yang ditentukan dalam package.json . Jika tidak ada rentang semver yang tersedia (yaitu Anda menjalankan npm outdated --global , atau paket tidak disertakan dalam package.json ), maka wanted menampilkan versi yang saat ini diinstal.

• latest adalah versi paket yang ditandai sebagai yang terbaru di registri. Menjalankan npm publish tanpa konfigurasi khusus akan menerbitkan paket dengan dist-tag latest . Ini mungkin atau mungkin bukan versi maksimum dari paket, atau versi paket yang paling baru diterbitkan, tergantung pada bagaimana pengembang paket mengelola dist-tag(1) terbaru.

• location adalah tempat di pohon dependensi paket tersebut berada. Perhatikan bahwa npm outdated default ke kedalaman 0, jadi kecuali Anda menimpanya, Anda akan selalu melihat hanya dependensi tingkat atas yang sudah usang.

• package type (saat menggunakan --long / -l ) memberi tahu Anda apakah paket ini adalah dependency atau devDependency . Paket yang tidak termasuk dalam package.json selalu ditandai dependencies .

Contoh

Edit package.json dan tambahkan "underscore": "1.7" ke daftar dependensi.

$ npm outdated
Package     Current  Wanted  Latest  Location
underscore  MISSING   1.7.0   1.8.3  underscore

$ npm install
[email protected] node_modules/underscore

$ npm outdated
Package     Current  Wanted  Latest  Location
underscore    1.7.0   1.7.0   1.8.3  underscore

JS Benang

Yarn CLI memiliki subperintah outdated bawaan untuk "memeriksa dependensi paket yang sudah ketinggalan zaman".

Referensi: https://yarnpkg.com/lang/en/docs/cli/outdated/

Keterangan

Mencantumkan informasi versi untuk semua dependensi paket. Informasi ini mencakup versi yang saat ini diinstal, versi yang diinginkan berdasarkan semver, dan versi terbaru yang tersedia.

Misalnya, katakanlah package.json Anda memiliki dependensi berikut yang terdaftar:

"dependencies": {
  "lodash": "4.15.0",
  "underscore": "~1.6.0"
}

Perintah run akan terlihat seperti ini:

yarn outdated
Package    Current Wanted Latest
lodash     4.15.0  4.15.0 4.16.4
underscore 1.6.0   1.6.0  1.8.3 
✨  Done in 0.72s.

Permata Ruby

Gems CLI memiliki sub-perintah outdated bawaan untuk "menampilkan semua permata yang perlu diperbarui".

Referensi: http://guides.rubygems.org/command-reference/#gem-outdated

Keterangan

(Dari ref.)

Perintah usang mencantumkan permata yang mungkin ingin Anda tingkatkan ke versi yang lebih baru.

Anda dapat memeriksa ketidakcocokan ketergantungan menggunakan perintah ketergantungan dan memperbarui permata dengan perintah pembaruan atau instal.

Ruby Bundler

Bundler CLI memiliki sub-perintah outdated bawaan untuk "mendaftar permata yang diinstal dengan versi yang lebih baru tersedia".

Ref: https://bundler.io/v1.11/bundle_outdated.html

Keterangan

(Dari ref.)

Kedaluwarsa mencantumkan nama dan versi permata yang memiliki versi lebih baru yang tersedia di sumber yang diberikan. Memanggil kedaluwarsa dengan [GEM [GEM]] hanya akan memeriksa versi yang lebih baru dari permata yang diberikan. Secara default, permata pra-rilis yang tersedia akan diabaikan.

Python PIP

PIP CLI ini list subcommand memiliki --outdated pilihan, untuk "daftar paket usang", dan --uptodate pilihan untuk "paket daftar uptodate".

Ref: https://pip.pypa.io/en/stable/reference/pip_list/

Contoh

Daftar paket yang diinstal.

$ pip list
docutils (0.10)
Jinja2 (2.7.2)
MarkupSafe (0.18)
Pygments (1.6)
Sphinx (1.2.1)

Daftar paket usang (tidak termasuk yang dapat diedit), dan versi terbaru yang tersedia.

```
$ daftar pip --kedaluwarsa
docutils (Saat ini: 0.10 Terbaru: 0.11)
Sphinx (Saat ini: 1.2.1 Terbaru: 1.2.2)

Kesimpulan:

1. Manajer paket JS dan Ruby memiliki subperintah outdated bawaan untuk mencantumkan paket "tidak bereputasi baik", dalam arti bahwa versi yang mereka instal bukan yang diminta, atau yang diminta bukan versi upstream terbaru ( belum tentu yang terbesar, tetapi yang terbaru ditandai sebagai rilis stabil).

2. Python PIP memiliki fungsi serupa melalui sub-perintah list bawaan, yang membuatnya lebih umum, tetapi lebih sulit ditemukan dan digunakan untuk pengguna pemula/rata-rata.

3. Sepertinya semua perintah ini hanya dapat dibaca dan tidak memiliki fungsi bawaan untuk memperbarui file manifes ke versi terbaru.

4. Saya belum melihat tanda-tanda fungsi seperti peringatan tentang paket kedaluwarsa di perintah lain.

Jadi, IMHO, kami dapat merencanakan untuk fungsi-fungsi ini, hanya berlaku untuk dependensi langsung dari suatu paket/ruang kerja.

a) Perintah outdated bawaan untuk membantu pengembang menemukan dependensi langsung yang sudah ketinggalan zaman. Ini akan menjadi output readonly dan output yang dapat dibaca manusia akan mirip dengan manajer paket JS/Ruby.

b) Perluas (a) untuk mendukung ruang kerja.

c) Tambahkan opsi ke outdated untuk membuatnya baca-tulis, memperbarui nomor versi dari satu/lebih/semua dependensi yang kedaluwarsa. Ini, saya berasumsi, akan menjadi satu-satunya/perintah kargo pertama yang menulis ke manifes, jadi akan membutuhkan lebih banyak pekerjaan desain dan implementasi.

d) Perluas (c) untuk juga mendukung ruang kerja.

Keduanya cukup untuk skrip shell dan perintah kargo pihak ketiga untuk dengan mudah membangun otomatisasi untuk peningkatan yang stabil, yang berarti menjalankan pengujian dengan peningkatan tunggal dan kembali jika ada kesalahan kompilasi atau pengujian.

Bagaimana menurut anda?

https://crates.io/crates/cargo-outdated berfungsi dengan baik hari ini

Sayangnya, paket cargo-outdated belum memiliki dukungan untuk ruang kerja.

Juga, pertanyaannya adalah tentang proposal asli untuk menambahkan peringatan opsional (mungkin sebagai keikutsertaan, melalui opsi env-var dan/atau cli) untuk cargo update tentang keberadaan paket yang kedaluwarsa. Saya ingin tahu bagaimana perasaan semua orang tentang itu.

Saya akan sangat kecewa karena menambahkan dukungan outdated di Cargo itu sendiri, tetapi kami mungkin ingin bekerja sama dengan penulis hulu cargo-outdated untuk memastikan kami berkoordinasi. Saya tahu saya cukup sering menggunakannya!

Juga terima kasih banyak telah melakukan penyelidikan itu @behnam , ini sangat membantu!

+1 besar untuk mendapatkan cargo outdated bawaan.

Saya telah menggunakan cargo-outdated selama berabad-abad sekarang tetapi seperti yang dikatakan @behnam , itu belum mendukung ruang kerja dan saya menggunakan begitu banyak dengan yarn dan pip sehingga saya percaya itu harus menjadi bagian dari Kargo.

Hanya untuk memperbarui output benang, sebenarnya terlihat seperti berikut sekarang:

Package            Current       Wanted  Latest  Package Type    URL                                                       
@types/lodash      4.14.70       4.14.71 4.14.71 devDependencies https://www.github.com/DefinitelyTyped/DefinitelyTyped.git
@types/react       15.0.38       15.0.39 15.0.39 devDependencies https://www.github.com/DefinitelyTyped/DefinitelyTyped.git
gulp               4.0.0-alpha.2 exotic  exotic  devDependencies gulpjs/gulp#4.0                                           
signature_pad      2.2.0         2.2.1   2.2.1   dependencies    https://github.com/szimek/signature_pad                   
webpack-dev-server 2.5.1         2.6.1   2.6.1   devDependencies http://github.com/webpack/webpack-dev-server              
Done in 2.27s.

Memiliki URL di output cukup bagus untuk dapat melihat perubahannya juga. Memisahkan dependensi dev, dependensi build, dan dependensi lebih rapi daripada yang dilakukan benang juga akan bagus, tetapi kemudian mungkin menjadi terlalu rumit untuk ditampilkan dengan ruang kerja.

Satu perubahan yang harus dilakukan dibandingkan dengan cargo-outdated yang telah disebutkan adalah bahwa imo, seharusnya hanya mencantumkan dependensi langsung dari proyek, bukan subdependensi. Berikut ini contoh di salah satu proyek saya:

    Name             Project Ver  SemVer Compat  Latest Ver
    hyper               0.10.12        --          0.11.1
    hyper->base64       0.5.2          --          0.6.0
    hyper->mime         0.2.6          --          0.3.2
    hyper->unicase      1.4.2          --          2.0.0
    slug->unidecode     0.2.0          --          0.3.0

Saya hanya peduli tentang hyper dalam daftar itu.

Jika kita ingin pergi c) Saya akan merekomendasikan memeriksa perintah yarn upgrade-interactive sebagai contoh bagaimana menanganinya.

Saya akan tertarik untuk melakukan implementasi jika itu akhirnya diterima untuk kargo!

Ide bagus, @Keats!

Memiliki URL di output cukup bagus untuk dapat melihat perubahannya juga.

Sepakat.

Juga, pada catatan yang sama, opsi --verbose yang menunjukkan Anda juga semua dalam performa yang baik, memberi tahu Anda apa yang ada di daftar periksa.

Memisahkan dependensi dev, dependensi build, dan dependensi lebih rapi daripada yang dilakukan benang juga akan bagus

Saya tidak yakin apa build-dependencies sini. Tapi, tentang dev-dependencies , setuju bahwa kadang-kadang itu bukan masalah dan lebih baik tidak memperhitungkannya. Jadi, mungkin kita memerlukan serangkaian opsi untuk menonaktifkan setiap grup dependensi ini.

tapi kemudian mungkin menjadi terlalu rumit untuk ditampilkan dengan ruang kerja.

Sebenarnya, saya pikir fungsi readonly tidak akan terlalu rumit untuk ruang kerja, karena diharapkan sudah ada satu Cargo.lock .

Namun, ini adalah pengingat yang baik bahwa kita juga membutuhkan sesuatu seperti NPM location , yang menunjukkan paket lokal (di ruang kerja) mana yang bergantung pada versi lama.

Dan sebagai nilai tambah, ini akan menjadi alat internal Cargo untuk memperingatkan ruang kerja (atau bahkan paket) yang memiliki ketergantungan langsung pada beberapa versi dari satu paket.

seharusnya hanya mencantumkan dependensi langsung proyek, bukan subdependensi.

Tepat. Saya tidak yakin apakah kami ingin fitur melakukan pemeriksaan ini lebih dari satu tingkat kedalaman. Saya pikir kita bisa mulai dengan deps langsung dan melihat apakah ada permintaan untuk opsi perpanjangan.

Saya akan tertarik untuk melakukan implementasi jika itu akhirnya diterima untuk kargo!

Luar biasa! Saya tidak akan dapat mencapai ini dalam beberapa minggu ke depan, tetapi dapat membantu dengan beberapa tes dan ulasan, jika diperlukan.

Jadi, sepertinya kami memiliki konsensus umum tentang fungsionalitas inti dari sub-perintah outdated bawaan dan sisanya dapat didiskusikan per PR, saya berasumsi.

Juga, mari kita CC penulis cargo-outdated . @kbknapp , apa pendapat Anda tentang ini?

Saya tidak yakin dependensi build apa yang ada di sini. Tapi, tentang dev-dependensi, setuju bahwa terkadang itu bukan masalah dan lebih baik tidak memperhitungkannya. Jadi, mungkin kita memerlukan serangkaian opsi untuk menonaktifkan setiap grup dependensi ini.

Membangun dependensi akan menjadi bindgen misalnya: https://github.com/compass-rs/sass-rs/blob/master/sass-sys/Cargo.toml#L16
Ketergantungan dev penting untuk ditampilkan di JS-land karena saya memiliki lebih banyak dependensi dev daripada dependensi yang sebenarnya, tetapi saya pikir masih masuk akal untuk menampilkan info usang untuk semua peti yang terdaftar di Cargo.toml saya secara default. Kami dapat memiliki tanda untuk menonaktifkan dependensi build/dev tetapi saya rasa itu tidak akan sering digunakan: jika Anda menjalankan cargo outdated , Anda biasanya ingin melihat semua peti.

Sebenarnya, saya pikir fungsi readonly tidak akan terlalu rumit untuk ruang kerja, karena diharapkan sudah ada satu Cargo.lock.

Kekhawatiran saya lebih pada bagaimana menampilkannya dengan baik di terminal ketika Anda memiliki banyak ruang kerja seperti habitat . Saya kira menggulir sedikit bukanlah masalah besar

Setuju, @Keats. :)

Hal yang lucu tentang build-dependencies : Saya tahu apa itu, tetapi tidak menemukannya di mana pun di bawah referensi manifes: http://doc.crates.io/manifest.html . Ternyata, itu hanya disebutkan di halaman lain ini: http://doc.crates.io/specifying-dependencies.html#build-dependencies Saya akan mengirimkan PR untuk menambahkannya ke daftar di http://doc.crates .io/manifest.html#dependency-sections agar tidak terjadi lagi.

@alexcrichton , apakah ini sesuatu yang memerlukan RFC, atau kita dapat melanjutkan dengan konsensus umum di sini dan memulai implementasi?

Jika tidak ada RFC, saya kira kita dapat membuat masalah pelacak baru untuk subperintah cargo outdated bawaan dengan detailnya, dan meninggalkan masalah ini untuk diskusi tentang hal-hal terkait lainnya, seperti peringatan yang diusulkan pada cargo update ketika ada paket yang tertinggal.

Maaf semuanya, saya baru saja melihat ini! Saya baik-baik saja dengan menambahkan perintah cargo outdated ! Saya tidak punya banyak waktu untuk mengerjakan proyek sumber terbuka akhir-akhir ini karena pekerjaan harian saya, tetapi @Frederick888 telah melangkah untuk membantu cargo-outdated secara khusus.

Hal terbesar yang saya lihat perlu terjadi untuk cargo-outdated (asli atau pihak ketiga) adalah menambahkan dukungan ruang kerja.

@Keats

Saya hanya peduli tentang hyper dalam daftar itu.

cargo-outdated (subperintah pihak ketiga) saat ini memiliki opsi -R, --root-deps-only atau --depth=# yang melakukan persis apa yang Anda cari.

Ada juga -r, --root=PKG untuk memperlakukan paket tertentu sebagai root, dan terakhir -p, --package=PKG untuk hanya mencari pembaruan untuk paket/peti tertentu. Semuanya juga harus bisa digabungkan.

Sedikit keluar dari topik, hal semacam ini memunculkan topik perintah pihak ketiga yang bergerak lebih dekat ke perintah asli, dan jika ada metode atau tempat resmi untuk hal ini terjadi? Mirip dengan bagaimana lib pindah ke pembibitan, apakah ada tempat di mana perintah pihak ketiga dapat bergerak lebih dekat ke cargo itu sendiri, bahkan mungkin didistribusikan secara default? Ada saat-saat di mana itu mungkin kurang berhasil daripada mengimplementasikan kembali fungsionalitas. Saya mengerti dengan outdated mungkin lebih mudah untuk hanya menduplikasi fungsi di dalam cargo , tapi saya sangat ragu ini adalah terakhir kalinya situasi seperti ini akan muncul. Hanya berpikir keras. :mengedip:

Saya hanya peduli tentang hyper dalam daftar itu.

cargo-outdated (subcommand pihak ketiga) saat ini memiliki opsi -R, --root-deps-only atau --depth=# yang melakukan persis seperti yang Anda cari.

Ada dua alasan Anda mungkin memiliki ketergantungan peti yang Anda gunakan. Entah pembuatnya belum memutakhirkan, atau Anda memiliki versi lama di file Cargo.lock . Kolom cargo-outdated SemVer Compat mungkin akan membantu di sini, tetapi saya tidak pernah tahu cara kerjanya, misalnya:

    Name                  Project Ver  SemVer Compat  Latest Ver
    rocket->base64           0.6.0        0.5.2           --

Jadi dari waktu ke waktu saya menghapus Cargo.lock untuk mendapatkan yang baru.

@lnicola

Saya tidak pernah tahu cara kerjanya

Kami baru saja membuat rilis baru. Bisakah Anda mengujinya lagi?

@kbknapp

Sedikit keluar dari topik, hal semacam ini memunculkan topik perintah pihak ketiga yang bergerak lebih dekat ke perintah asli, dan jika ada metode atau tempat resmi untuk hal ini terjadi?

Poin bagus. Sebenarnya ketika saya sedang refactoring cargo-outdated Saya banyak berjuang tentang apakah akan menambahkan cargo sebagai dependensi karena cenderung berlebihan (dan akan menghabiskan banyak waktu untuk membaca dokumen) . Tetapi sekarang jika kita berbicara tentang menyematkan fungsionalitas ke dalam cargo itu sendiri, yang merupakan sesuatu yang saya juga senang, tampaknya bergantung pada cargo adalah pilihan yang lebih baik.

Jadi ya, akan lebih baik untuk memiliki pedoman seperti itu, atau bahkan daftar saran pengembangan sub-perintah untuk pengembang.

Saya benar-benar mencari versi baru ketika Anda menulis itu .

Sebelum:

    Name                  Project Ver  SemVer Compat  Latest Ver
    rocket->base64           0.6.0        0.5.2           --
    r2d2-diesel->diesel      0.15.1       0.15.2        0.15.2
    rocket->hyper            0.10.12        --          0.11.2
    time->libc               0.2.28       0.2.29        0.2.29
    uuid->rand               0.3.15       0.3.16        0.3.16
    time->redox_syscall      0.1.27       0.1.29        0.1.29
    toml->serde              1.0.10       1.0.11        1.0.11
    rocket->smallvec         0.4.1          --          0.2.1
    rocket_contrib->tera     0.10.8       0.10.9        0.10.9
    rocket->toml             0.4.2        0.4.4         0.4.4

Setelah:

Name                         Project Ver  SemVer Compat  Latest Ver
backtrace->libc                 0.2.28       0.2.29        0.2.29
backtrace-sys->libc             0.2.28       0.2.29        0.2.29
diesel                          0.15.1       0.15.2        0.15.2
diesel_codegen->diesel          0.15.1       0.15.2        0.15.2
diesel_infer_schema->diesel     0.15.1       0.15.2        0.15.2
isatty->libc                    0.2.28       0.2.29        0.2.29
memchr->libc                    0.2.28       0.2.29        0.2.29
num_cpus->libc                  0.2.28       0.2.29        0.2.29
r2d2-diesel->diesel             0.15.1       0.15.2        0.15.2
rand->libc                      0.2.28       0.2.29        0.2.29
rayon-core->libc                0.2.28       0.2.29        0.2.29
rayon-core->rand                0.3.15       0.3.16        0.3.16
ring->libc                      0.2.28       0.2.29        0.2.29
rocket->toml                    0.4.2        0.4.4         0.4.4
rocket_contrib->serde           1.0.10       1.0.11        1.0.11
rocket_contrib->tera            0.10.8       0.10.9        0.10.9
serde                           1.0.10       1.0.11        1.0.11
serde_json->serde               1.0.10       1.0.11        1.0.11
tera->serde                     1.0.10       1.0.11        1.0.11
time->libc                      0.2.28       0.2.29        0.2.29
time->redox_syscall             0.1.27       0.1.29        0.1.29
toml->serde                     1.0.10       1.0.11        1.0.11
uuid->rand                      0.3.15       0.3.16        0.3.16

Setelah menghapus Cargo.lock :

All dependencies are up to date, yay!

👍

Setelah menghapus Cargo.lock:

@lnicola , apakah Anda mengatakan bahwa cargo update tidak memberi Anda hasil yang sama? Jika demikian, dapatkah Anda sedikit lebih spesifik dalam situasi apa yang terjadi?

@behnam Saya sebenarnya punya salinannya, jadi saya hanya mencoba cargo update di atasnya. Sepertinya hasilnya sama ("Semua dependensi terbaru").

Jika Anda bertanya mengapa saya mengatakan saya menghapus Cargo.lock alih-alih menjalankan cargo update , tidak ada alasan khusus.

@Frederick888 Melihat output saya, saya pikir pembaruan semver-breaking untuk dependensi tidak dilaporkan lagi?

    rocket->hyper            0.10.12        --          0.11.2

@lnicola Sebenarnya itu tidak seharusnya dilaporkan. Sebelumnya jika sebuah paket memiliki beberapa kejadian dengan versi/persyaratan semver yang berbeda di pohon dependensi, program mungkin berperilaku tidak semestinya dari waktu ke waktu.

cargo-outdated memeriksa versi "terbaru" dengan mengganti persyaratan semver dari dependensi langsung dengan "*" , yang berarti itu tidak benar-benar memberi Anda versi "terbaru dirilis" dari yang tidak langsung . Ini terkadang tidak cukup intuitif dan ada masalah terkait untuk ini (kbknapp/cargo-outdated#25).

Sebelumnya jika sebuah paket memiliki beberapa kejadian dengan versi/persyaratan semver yang berbeda di pohon dependensi, program mungkin berperilaku tidak semestinya dari waktu ke waktu.

Saya tidak berpikir itu adalah kasus untuk hyper dalam contoh saya.

memeriksa versi "terbaru" dengan mengganti persyaratan semver dari dependensi langsung dengan "*", yang berarti itu tidak benar-benar memberi Anda versi "terbaru dirilis" dari yang tidak langsung.

Jadi begitu. Mungkin berguna untuk melaporkannya, jadi Anda tahu bahwa dependensi Anda menggunakan peti yang lebih lama. Tapi saya tidak merasa terlalu kuat tentang hal itu.

Mengenai mempermudah perpustakaan pihak ketiga untuk menggunakan internal cargo , dan membuatnya lebih mudah untuk memasukkan perintah pihak ketiga sebagai bawaan: mungkin membagi kargo menjadi peti yang lebih kecil (dalam satu repo, atur sebagai ruang kerja ) akan membantu?

Pada dasarnya, saya pikir membaca dan memvalidasi manifes (dengan pemahaman tentang ruang kerja dan berbagai dependensi) harus menjadi perpustakaan terpisah dari perintah yang menggunakan manifes untuk mengambil tindakan.

Ada banyak diskusi dalam masalah ini tentang banyak topik-- internal mungkin menjadi tempat yang lebih baik untuk diskusi tersebut.

Setelah membaca, sepertinya masalah yang paling terfokus di sini adalah memindahkan cargo outdated di pohon menjadi perintah yang didukung secara resmi, jadi saya telah mengubah judul masalah untuk mencerminkan hal itu.

Saya percaya beberapa kebingungan tentang "mengapa cargo-outdated menunjukkan X " juga berasal dari https://github.com/kbknapp/cargo-outdated/issues/134 , yang saya hanya tersandung pada.

Apakah ada kemajuan saat ini dalam hal ini? Adakah yang tahu apa status terakhir ini di hulu?

Apakah kami memiliki pembaruan untuk ini? Saya suka cargo-outdated meskipun saya pikir harus ada sub-perintah standar di dalam kargo yang memeriksa paket yang sudah usang. Karena pengguna baru perlu mencari paket hanya untuk menjalankan fungsi tertentu itu

Hanya meninggalkan catatan di sini bahwa pohon kargo baru-baru ini diadopsi menjadi kargo yang tepat di https://github.com/rust-lang/cargo/pull/8062 , yang, setidaknya bagi saya, menunjukkan bahwa bukan tidak mungkin hal yang sama dapat terjadi pada kargo usang jika seseorang melakukan pekerjaan.

cc @deg4uss3r

Terima kasih untuk cc @kbknapp Saya sedang menyelesaikan pekerjaan saya saat ini, tetapi saya harus lebih bebas mulai minggu depan untuk benar-benar melihat ini :)

Hei, apakah kamu bisa melihat kemungkinan ini?

@svenstaro Ya saya punya! Kemajuan bergerak lambat, tetapi saya sedang mengusahakannya :) memulai pekerjaan baru pada saat yang sama itu sulit

Oke sayang, terima kasih atas pembaruannya!

@deg4uss3r ramah ping :D

@svenstaro Terima kasih banyak telah membuat saya jujur!

Jadi, saya sedang mengerjakan ini; namun, saya telah melakukannya secara offline karena saya melihat banyak hal kecil untuk diperbaiki pada cargo-oudated yang ingin saya sederhanakan sebagai sub-perintah kargo, tetapi masih mungkin mempertahankan cargo-outdated sebagai opsi berbasis proyek yang lebih berat. Jadi, inilah pekerjaan saya di tempat terbuka: https://github.com/deg4uss3r/outdated2

Ini akan terlihat SANGAT kasar sekarang, maaf sejauh ini tahun 2020 cukup menarik!

Jadi ini menyederhanakan proyek hingga hanya melihat dependensi ruang kerja dan meminta yang terbaru dari https://crates.io melalui API. Saya pikir ini adalah pilihan terbaik untuk ditambahkan ke kargo karena kami ingin itu selalu berfungsi tidak ada lagi masalah kompilasi dengan dependensi yang saling bertentangan dan itu hanya akan memeriksa dependensi yang sudah ketinggalan zaman dari proyek saat ini daripada menyelam ke dalam dependensi yang tidak dapat dikendalikan oleh peluncur .

Ada BANYAK (seperti yang Anda tahu) yang harus saya kerjakan yang terbesar adalah mengintegrasikan dengan cargo secara langsung, tetapi saya telah memperhatikan dependensi yang digunakan cargo untuk memastikan saya sedang menggunakan kembali apa yang sudah diimpor. Sejauh ini saya melihat bahwa saya harus benar-benar menyempurnakan sebelum benar-benar memasukkan kargo untuk MR:

• [ ] Hanya laporkan pembaruan pada saluran tempat ketergantungan berada (mis., jangan tawarkan versi beta saat pengguna menggunakan versi stabil)
• [ ] Penanganan kesalahan yang tepat
• [ ] Integrasi baris perintah untuk opsi
• [ ] dukungan untuk mengeluarkan json

Saya ingin beberapa pendapat tentang versi yang diperkecil ini sebelum saya melanjutkan lebih jauh karena, secara pribadi saya pikir inilah yang kami inginkan sebagai sub-perintah cargo , tetapi saya mungkin benar-benar minoritas di sana.

Sunting: Saya yakin ada beberapa pengoptimalan yang sangat sederhana yang belum saya lakukan tetapi saat ini cukup cepat, dibutuhkan sekitar 9 detik (rilis build, dari rustc stable 1.46 ) untuk servo ... 'tidak buruk untuk sesuatu seperti ini!

Bagus untuk melihat beberapa kemajuan!

Karena Anda meminta umpan balik: Fitur yang sangat saya sukai di versi saat ini: --ignore , --depth , --workspace . --exit-code menarik untuk CI.

Saya cukup sering menggunakan cargo outdated -R/--root-deps-only , karena output standarnya agak bertele-tele.

Saya sarankan melihat yarn upgrade-interactive --latest untuk antarmuka pemutakhiran yang benar-benar bersih. Saya sering menggunakan kargo yang ketinggalan zaman, tetapi harus mengubah setiap dep secara manual itu menyebalkan.