Fabric: Pisahkan fitur yang tidak bergantung pada ssh menjadi lib terpisah

:kue:

Alat yang benar-benar baru yang sesuai dengan kasus penggunaan juga selalu menjadi pilihan, tentu saja.

Deskripsi yang diperbarui banyak.

@kennethreitz : ini benar-benar akan menjadi "hal" baru, hanya berdasarkan set kebutuhan/fitur yang ada dari separuh Fabric. Idenya adalah untuk menjadi entitasnya sendiri: instalasi, jadwal pengembangan, dll, tetapi masih dikendalikan oleh pengembang/komunitas Fabric.

Ide ide:

• tony - seperti dalam Tony Masters alias The Taskmaster (buku komik~)
• CEO - Menjalankan sesuatu, (atau tsar atau yang serupa di sepanjang garis itu)

Maaf saya payah menyebut nama :(

Juga hal-hal seperti "kirk" (seperti dalam kapten kirk).

Saya mencoba memikirkan sesuatu yang terkait dengan fabric yang berkaitan dengan menjalankan tugas tetapi saya tidak dapat memikirkan yang terkait dengan tugas + fabric.

Tapi Loom juga bukan nama yang buruk menurutku.

Nama awal brainstorming.

Konsep

• Lari/joging/dll
• Eksekusi (perintah, orang mungkin meskipun itu agak mengerikan, dll)
• Tugas (seperti dalam hal-hal yang harus dilakukan, tugas, dll)
• Mungkin beberapa nama yang ditolak atau serupa dari #461, sejauh gagasan menenun atau menyatukan sesuatu dari kain juga berlaku untuk tugas

Nama tidak diambil di PyPI

• runner
• executor
• go
  
  
  
  • Kebingungan dengan bahasa pemrograman dan/atau permainan papan, terutama jika yang pertama memiliki biner yang secara khusus disebut go
  
  
  • Baik atau buruk, memiliki banyak nama tugas konyol yang potensial seperti away atau fuck_yourself atau bother_somebody_else
  
  
• weaver

Nama biner

Terima kasih, Tesaurus Penulis Amerika Oxford seperti yang disajikan oleh aplikasi Kamus OS X!

• run
• execute
• go
  
  
  
  • Lihat di atas
  
  
• create (seperti make )
• fabricate (terlalu panjang, terlalu mudah bingung dengan fab )
• fab (yaitu memiliki lib baru yang diberi nama berbeda tetapi masih menginstal biner fab ; jika keduanya ada di sistem, Fabric yang diutamakan? Sepertinya ide yang bodoh.)
• generate
• produce
• fashion (meh)
• build
• devise
• shape
• setup
• weave

Tidak dalam bentuk curah pendapat teratas hari ini. Ingin tegalan.

@dstufft Loom adalah nama yang OK, dan CEO adalah konsep yang sebagian besar baik-baik saja (bukan penggemar berat referensi buku komik, jika hanya karena tampaknya tidak jelas, saya belum pernah mendengar karakternya ;)). Masalah utama adalah menghasilkan nama biner yang bagus, saya merasa kata kerja adalah suatu keharusan agar bisa berfungsi dengan baik. Tidak yakin apa yang akan berhasil untuk keduanya.

Bos: Menjalankan sesuatu.

mengambil bagian. Agak seperti Make, tapi untuk Python.

Eksekutif.

Saya suka ide itu berorientasi pada tugas. Hmm..

@kennethreitz Saya suka Bos, selain potensi kebingungan dengan penduduk asli New Jersey tertentu (maaf, hanya bukan penggemar, pengalaman teman sekamar yang buruk di perguruan tinggi)

Seperti yang saya katakan kepada @dstufft , nama biner jelas merupakan kunci di sini, jadi jika Anda bisa, cobalah untuk mengingatnya juga. Nama proyek yang bagus tidak membantu jika nama proyek sebagai biner terdengar agak bodoh;)

Pembantu itu menarik. Melakukan tugas Anda untuk Anda. Mirip dengan "Membuat".

Pelayan juga. Kita bisa memilih nama pelayan yang terdengar seperti orang Inggris secara acak.

maid clean , maid release , maid test . Saya suka itu.

Selain mempengaruhi kejantanan saya (tanpa batas, tentu saja), maid cukup bagus, meskipun tidak sesuai dengan pola kata kerja. (Yaitu itu adalah salah satu nama biner non-verba yang lebih baik.) (EDIT: dan apa yang butler _do_? Butle?)

Saya hanya jongkok namanya, untuk jaga-jaga. Saya sangat menyukainya sejauh ini.

Boss sebagai nama perpustakaan sudah diambil FWIW

Pada hari Selasa, 21 Februari 2012 pukul 20:38, Jeff Forcier menulis:

Selain mempengaruhi kejantanan saya (tanpa batas, tentu saja), maid cukup bagus, meskipun tidak sesuai dengan pola kata kerja. (Yaitu itu adalah salah satu nama biner non-verba yang lebih baik.)

---

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/fabric/fabric/issues/565#issuecomment -4095609

intern juga merupakan pilihan yang luar biasa.

@dstufft Jadi, dan saya juga tidak bisa memikirkan nama biner yang bagus untuk itu, boss docs tidak terlalu cocok.

@kennethreitz menyebutkan $# $ bake docs bake di IRC, yang sesuai dengan tema make/rake, dan juga cocok sebagai kata kerja yang dipanggil (mis. d lebih cocok di Chef atau sesuatu.

EDIT: juga deliver . Reaksi awal saya terhadap yang satu ini agak positif ( $ deliver build $ deliver docs ) tetapi tidak ada nama proyek _great_ yang bisa digunakan yang tidak terlalu konyol, dan agak panjang.

$ invoke taskname (nama proyek: invoker , invoked , ???)

Dipanggil.

Saya sangat suka Dipanggil dan invoke docs invoke tests invoke publish dll.

Nama proyek bisa saja "Invoke" juga, apakah biner dan proyek memerlukan nama yang berbeda?

Saya pikir 'dipanggil' memiliki lebih banyak pizzazz daripada 'meminta', tetapi keduanya bisa berhasil.

Nama tidak harus berbeda, tidak, hanya saja berkali-kali lebih masuk akal.

Saya memiliki pemikiran saat berjalan ke kereta (di kereta tersebut sekarang: P go go smartphone tethering!) yaitu bahwa kita _bisa_ mungkin melewatkan semua ini dan cukup memindahkan seluruh sisi fab + fabfile.py hal-hal ke perpustakaan "baru" ini (dan sebut saja, katakanlah, fabricator ).

Dengan kata lain, memiliki satu yang dapat dipanggil untuk lib mandiri dan yang berbeda untuk penyiapan penggunaan SSH tidak selalu harus terjadi, dan bahkan dapat merugikan.

Plus:

• Tidak perlu nama biner baru
• Bagaimanapun, memiliki dua nama biner akan membingungkan
• Jika lib baru _didn't_ menggunakan "fabfiles", kami juga akan memiliki dua jenis "file tugas" yang berbeda, sekali lagi membingungkan/kode tambahan/dll

Minus:

• Potensi kebingungan antara kedua proyek karena nama yang mirip
• Proyek baru harus ekstra dapat diperluas untuk memungkinkan semua Fabric-isme (misalnya hampir semua flag CLI, dll) untuk terus bekerja apa adanya
  
  
  
  • Yaitu pip install fabricator memberi kita fab , yang akan memiliki beberapa set flag yang lebih kecil
  
  
  • Kemudian jika Anda pip install fabric , tiba-tiba fab yang sama harus menunjukkan semua flag Fabric CLI tambahan, jika bukan hal lain juga
  
  
  • OTOH tidak seperti mengizinkan kode "klien" untuk memperluas penguraian CLI adalah hal yang _buruk_, hanya saja lebih banyak pekerjaan yang harus dilakukan di depan.
  
  

Anda dapat membuat klien baris perintah menjadi dapat diperluas. Lihatlah bagaimana hidung memungkinkan titik masuk plugin diekspresikan dari alat baris perintahnya

Saya pikir ekstensibilitas ekstra akan menjadi hal yang baik terlepas dari ke mana arahnya.

Kebingungan nama akan menjadi masalah yang saya pikir.

Ini adalah hal pribadi tapi saya suka tampilan invoke test invoke docs lebih baik dari fab test .

Sejauh binari yang berbeda pergi, saya hanya akan memastikan biner inti (memanggil) dapat diperluas untuk memungkinkan semua hal-hal fabrikasi terjadi, dan kemudian fab panggil saja titik masuk yang sama dengan yang dipanggil (yaitu binari fab/invoke yang sebenarnya hanya akan menjadi penelepon ultra minimalis dari main() (atau apa pun).

Saya pikir jika Anda menggunakan rute panggilan + kain yang sebelum 2.0 baik fabfiles dan "Invokefiles"? akan didukung, dan kemudian dengan 2.0 hanya Memanggil file?

Jadi pada dasarnya saya memberi +1 untuk membaginya menjadi "pelari tugas" dan "barang jarak jauh/ssh" yang berbeda, memasukkan shim compat untuk 1.x, dan mencela barang untuk 2.x. Perpecahan ini saya pikir akan membuat kedua lib lebih baik, pelari tugas akan mendukung beberapa kemampuan ekstensi yang sangat bagus (dan mungkin tugas eksternal yang dapat dengan mudah diandalkan, dijalankan, dll). Dan hal-hal jarak jauh/ssh akan mendapat manfaat dari memiliki serangkaian tanggung jawab yang lebih kecil yang memungkinkannya lebih fokus/

sen saya anyways.

Saya harus mengklarifikasi saya tidak membenci sebaliknya, saya senang diskusi ini terjadi sama sekali :)

@dstufft Terima kasih banyak atas pemikirannya, saya setuju dengan hampir semua itu. Anda benar tentang binari yang hanya menjadi rintisan, begitulah cara Fabric bekerja sekarang, perhatian saya semata-mata tentang perilaku dan kebingungan pengguna.

@dcolish Saya tidak bermaksud menyiratkan bahwa tidak mungkin melakukan ekstensi CLI, dan hidung jelas merupakan seni sebelumnya yang baik untuk diperiksa.

Jika kita menggunakan "invoke", mungkin nama filenya adalah invocations(.py) ? Sentuhan di sisi konyol/taman hiburan, tetapi cocok secara tata bahasa, dan invokefile.py terasa sedikit canggung bagi saya. Atau mungkin pergi ke rute konvensi Rake dan cukup gunakan tasks(.py) .

Sebagian terkait, saya pikir kita juga harus menghentikan/fokus pada aspek modul/folder ke depan. Karena Just Python masih akan didukung, tetapi dalam hal materi tutorial dan dokumen, menjadikan invocations/__init__.py sebagai default mungkin merupakan hal yang baik untuk dilakukan.

Saya suka tasks.py . invocations.py aneh untuk diketik.

Bukannya Anda harus mengetiknya terlalu sering, kan? ;) Tapi ya, tasks/ atau tasks.py sedikit lebih jelas secara global.

file tugas.py

Anda invoke tugas(.py|/), kata-katanya bagus :)

Ya, pengaturan "ini adalah tasks yang Anda invoke " bekerja dengan sangat baik dari perspektif mengikat kata kunci dengan deskripsi bahasa Inggris tentang cara kerjanya. Jelas, tanpa embel-embel, tanpa kesombongan, dll.

@kennethreitz Saya tidak pernah benar-benar _been_ penggemar berat XYZFile sebagai konvensi penamaan, dan terutama karena akhir-akhir ini sering _bukan_ satu file, saya rasa tidak perlu melanjutkan konvensi di luar Fab 1.x :)

Saya benar-benar akan senang melihat ini terjadi. Saya selalu melihat Fabric sebagai cara Pythonic generik untuk menyimpan "tugas" untuk sebuah proyek, apakah itu berbasis lokal atau jarak jauh, sesuatu yang lebih dekat dengan Rake/Make. Namun, ketika mencoba mengenalkan orang baru, beberapa orang bingung dengan sudut pandang ini dan melihatnya hanya sebagai alat penyebaran.

Saya akan mendukung aspek modul/folder, agar lebih mudah membuat tugas-tugas umum yang bisa dilakukan. Tugas gaya baru pasti berjalan dengan baik ke arah itu.

@askedrelic Yup, sayangnya menjadi dua hal dalam satu selalu sedikit membingungkan.

Tidak terkait: Saya memanggil @tswicegood ke utas ini karena dia dan saya mendiskusikan masalah ini beberapa minggu yang lalu dan saya pikir dia mungkin ingin mempertimbangkan. Seperti biasa saya berhak untuk tidak setuju ;)

saya dipanggil? :-)

Saya menyukai gagasan untuk pindah ke tasks sebagai modul daripada fabfile . Lebih masuk akal dan lebih pendek. Saya, untuk satu, benci harus menginstal dep stack penuh hanya untuk dapat menjalankan fab test di dalam Armstrong, jadi apa pun yang dapat dilakukan untuk mengekstrak bahwa saya adalah plus satu besar.

Sejauh penamaan, bagaimana dengan beralih dari memiliki executable eksternal yang diinstal ke meminta orang menambahkan ini ke bawah:

if __name__ == "__main__":
    <some_mod>.main()

Kemudian Anda hanya menggunakan Python. Saya baik-baik saja dengan executable, hanya tidak tahu apakah itu perlu.

FWIW, saya memulai proyek beberapa minggu yang lalu untuk menangani pembuatan paket yang disebut flunky . Berpegang pada tema petugas itu, footman atau lacky keduanya tersedia (yang terakhir memiliki konflik dengan lackie -- proyek Ruby). Yang lain adalah hari Jumat, seperti pada hari Jumat perempuan/laki -laki. Ini lulus tes GitHub/PyPI/Homebrew karena tidak ada yang bernama itu. Sebenarnya, sekarang aku memikirkannya, itu akan menjadi pilihan pertamaku.

Taruhan sampingan, saya bertanya-tanya berapa lama sampai @niran mengirimkan PR memperbarui README untuk memasukkan lagu tema yang jelas, meskipun mengerikan.

Saya pikir memiliki pada Anda- $PATH "biner" (terutama mengingat saat ini _bukan_ biner nyata tetapi hanya rintisan yang dibuat oleh setuptools yang memanggil (invoked|fabric).main() ) adalah yang paling ramah pengguna , dan saya tidak melihat manfaat apa pun untuk memindahkan konten rintisan itu untuk dibuat secara otomatis di dalam modul tugas (dan sebenarnya melihat sejumlah kelemahannya.)

Dan ya, inti dari ini adalah untuk berakhir dengan lib yang memungkinkan Anda mendapatkan hal-hal yang mudah dilakukan tanpa memerlukan deps SSH/jaringan/crypto :)

Saya sepenuhnya setuju dengan @bitprophet pada executable. Itu membuatnya lebih mudah untuk berlari. Jika seseorang ingin menggunakan sesuatu selain invoke / fab pada proyek pribadi mereka, itu hanya sebuah rintisan sehingga Anda dapat dengan mudah membuat biner Anda sendiri (dan dapat dengan mudah hidup di finalname.__main__.main , dalam hal ini Anda juga bisa hanya python -m finalname jika Anda mau juga.

+1.

Hanya melemparkan ide di luar sana, saya pikir itu lebih nyaman juga. FWIW, saya mendaftar Jumat di PyPI jika Anda ingin menggunakannya.

@bitprophet Maaf, saya pikir Anda tahu tentang cara menggunakan titik masuk. Saya memilih, dengan cara saya sendiri, untuk melakukan frontend dengan cara yang mirip dengan hidung dan menjaga nama tetap bagus.

Idenya bagus, saya suka ide :)

Friday sedikit terlalu imut, meskipun saya suka referensi budaya pop. Lagu itu sangat bagus! :muka mengejek:

Saya pikir untuk saat ini saya akan langsung ke invoke sebagai nama paket/proyek, dan biner. Astaga! Invoker atau Dipanggil adalah kemungkinan lain untuk yang pertama (yaitu masih dengan biner invoke ) tapi saya tidak bisa memikirkan alasan bagus untuk tidak memilih rute langsung.

Kelemahan utama dari nama ini adalah sifat generiknya, tetapi itu adalah masalah dengan setiap proyek yang pernah saya ambil alih atau buat, dan dalam hal ini tidak ada opsi yang lebih spesifik yang terasa benar bagi saya. /pembenaran

@dcolish Diakui, terima kasih!

Saya belum membuat keputusan akhir, tetapi saya pikir pada titik ini pendekatan yang masuk akal adalah:

• Invoke adalah miliknya sendiri, memiliki identitas/"merek" baru, menggunakan biner invoke , mencari modul tasks , dll.
  
  
  
  • Ini bersih, secara konseptual langsung untuk pengguna yang hanya menggunakan Invoke dan bukan Fabric, menghilangkan bagasi historis, dll
  
  
• Invoke memperlihatkan kode bersama apa pun yang mungkin ingin digunakan Fabric (atau alat lain), sebagai API publik
• Fabric terus menggunakan fab dan mencari modul fabfile , sambil menambahkan ketergantungan waktu penginstalan pada Invoke, dan menggunakan API Invoke untuk memanggil kode bersama itu
  
  
  
  • Ini berarti bahwa menginstal Fabric menghasilkan dua binari, tetapi dari perspektif pengguna yang berfokus pada Fabric, mereka tidak perlu _tahu_ bahwa invoke / tasks ada/adalah opsi, karena opsi tersebut' d tidak pernah menggunakannya -- fab masih merupakan superset fungsionalitas.
  
  
  • Pengguna yang ingin menggunakan kedua Invoke untuk kepentingannya sendiri (mis. dalam proyek lain yang tidak memiliki Fabfiles) _and_ Fabric adalah poin penting, re: bagaimana invoke dan fabric berhubungan satu sama lain dan berperilaku . Orang-orang ini mungkin tertarik pada invoke dan fab sebagai alias sederhana satu sama lain (yaitu dengan menginstal Fabric mengubah perilaku invoke , seperti cara kerja plugin Nose.)
  
  
  • Namun, saya pikir yang terbaik adalah memiliki keduanya berperilaku berbeda -- fab _harus_ membedakan _setidaknya_ dalam "nama modul tugas apa yang saya cari?" masuk akal, pada titik mana kita mungkin juga memilikinya sebagai makhluknya sendiri, dan hubungan antara Fabric dan Invoke hanya dalam cara Fabric menggunakan basis kode Invoke.
  
  

EDIT: Saya harus melihat _how_ ini akan bekerja, dengan cepat, sebelum membuat sesuatu yang final. Praktek vs teori dan semua itu. Mungkin mengalami sudut yang tidak saya pikirkan di sini.

Invoke memiliki rilis beta sekarang (setelah banyak pekerjaan baru-baru ini membangunnya). Sudah di:

• Lebih baik, lebih eksplisit tetapi masih hampir nol-boilerplate namespace
• Pengurai flag CLI "nyata", tidak ada lagi foo:bar,lol , termasuk terjemahan otomatis fungsi argspec ke dalam spesifikasi CLI
• Mencoba merancang bit eksekusi tugas agar dapat diperluas/ditimpa ulang: paralelisasi
• Yang dilakukan untuk mendukung: pra-tugas (menunjukkan tugas yang akan dijalankan sebelum tugas lain)
• pelari tugas lokal yang mampu menangkap-dan-cetak run (walaupun mungkin tidak berfungsi pada Windows)
• Mungkin melupakan beberapa bit lagi?

Berlari di atasnya dan berharap untuk mulai membuat prototipe bagaimana Fab 2 akan melesat ke atasnya, minggu ini.

pastikan bersih
memastikan dibangun
"memastikan" "menyatakan"

Apa status kain 2? Apakah ada garpu di luar sana yang menutupi ini? Maksud saya hal-hal yang harus dicakup oleh fabric2 yang tidak dipanggil.

@mvaled Ini akan segera muncul, telah berada di cabang 'bersih' pribadi dari repo kain.

Maaf jika ini keluar dari topik tetapi saya harus bertanya lagi:
Di mana saya dapat menemukan kain 2?
Saya sangat suka panggilan dan rasanya seperti peningkatan besar, tetapi apa yang hilang untuk rilis panggilan 1.0? (dijelaskan sebagai dasar untuk kain 2)

Terima kasih untuk semua pekerjaan hebat dalam panggilan dan kain!

@dmr Saya sedang membuat Fabric 2 bekerja di atas Invoke. Banyak fitur yang akan dipindahkan dari Fabric 1 akan menginformasikan keputusan desain untuk Invoke (untuk fitur baru atau yang sudah ada - misalnya perombakan konfigurasi baru-baru ini adalah salah satunya), jadi saya tidak ingin memberi label Invoke 1.0 sampai sudah " pertempuran diuji" secukupnya.

Rencana saya adalah menyiapkan alpha Fabric 2 untuk publik paling lambat oleh PyCon (idealnya lebih cepat) dan itu akan mengarah ke Fabric 2.0 + Invoke 1.0.

Terima kasih atas penjelasannya, ada yang bisa saya bantu?

Saya sedang mengerjakannya di cabang pribadi untuk jangka pendek sampai saya mendapatkan sesuatu yang saya senangi dan akan diumumkan di twitter/milis/dll setelah saya siap untuk umpan balik, jadi harap tetap disini.

Saya mulai beralih untuk memanggil dalam kombinasi dengan perintah Shell dan beberapa Paramiko karena fabric adalah paket terakhir tanpa dukungan python3 di proyek saya

Adakah ETA untuk Fabric 2.0 dan Invoke 1.0 karena Python 3.5 dirilis kemarin dan akan menjadi default di Ubuntu 16.04 LTS?