คำถามติดแท็ก packages

2
ชื่อแพ็คเกจควรเป็นแบบเอกพจน์หรือพหูพจน์
บ่อยครั้งที่ในไลบรารีโดยเฉพาะแพ็คเกจประกอบด้วยคลาสที่ถูกจัดระเบียบรอบ ๆ แนวคิดเดียว ตัวอย่าง: XML, SQL, การใช้งานการตั้งค่า, DB ผมคิดว่าเราทุกคนรู้สึกรักธรรมชาติที่แพคเกจเหล่านี้ถูกต้องในเอกพจน์ com.myproject xml . โครงการส่วนเสริมทั้งหมด SQL .Connection com.myproject ผู้ใช้ .User com.myproject ผู้ใช้. UserFactory อย่างไรก็ตามถ้าฉันมีแพ็คเกจที่มีชุดของการใช้งานประเภทเดียว - เช่นงาน, กฎ, ตัวจัดการ, แบบจำลอง ฯลฯซึ่งเป็นที่นิยมมากกว่า? com.myproject ภารกิจ. TakeOutGarbageTask com.myproject ภารกิจ. DoTheDishesTask com.myproject งาน.เพ้นท์เฮาส์เฮาส์ หรือ com.myproject ภารกิจ. TakeOutGarbageTask com.myproject ภารกิจ. DoTheDishesTask com.myproject task .PaintTheHouseTask

1
โมดูลเทียบกับแพ็คเกจ?
เมื่อใดก็ตามที่ฉันทำfrom 'x' import 'y'ฉันสงสัยว่าอันไหนที่ถือว่าเป็น 'โมดูล' และอันไหนคือ 'แพ็คเกจ' และทำไมมันจึงไม่มีวิธีอื่น
140 python  packages  modules 

5
เหตุใดจึงไม่มีระบบการจัดการแพ็คเกจสำหรับ C และ C ++ [ปิด]
มีภาษาการเขียนโปรแกรมบางอย่างซึ่งมีอยู่ในระบบการจัดการบรรจุภัณฑ์: CTANสำหรับ TeX CPANสำหรับ Perl Pip & Eggsสำหรับ Python Mavenสำหรับ Java พันธมิตรสำหรับ Haskell อัญมณีสำหรับทับทิม npmสำหรับ NodeJS bowerสำหรับ Javascript & CSS ส่วนหน้า นักเก็ตสำหรับ C # นักแต่งเพลงสำหรับ PHP มีภาษาอื่นที่ใช้ระบบดังกล่าวหรือไม่? แล้ว C และ C ++ ล่ะ? (นั่นเป็นคำถามหลัก!) ทำไมไม่มีระบบดังกล่าวสำหรับพวกเขา? และไม่ได้มีการสร้างแพคเกจสำหรับyum, apt-getหรือระบบการจัดการแพคเกจอื่น ๆ ทั่วไปดีขึ้นหรือไม่
78 c++  c  builds  packages 

9
เหตุใดจึงต้องใช้ตัวจัดการแพคเกจเหนือโฟลเดอร์ไลบรารี
เมื่อฉันคิดถึงข้อดีข้อเสียของโฟลเดอร์ไลบรารี่แบบคงที่และตัวจัดการแพ็กเกจฉันรู้สึกว่าโฟลเดอร์ไลบรารี่เป็นวิธีที่ดีกว่า ข้อดีที่ฉันเห็นด้วยโฟลเดอร์ไลบรารี: ไม่จำเป็นต้องมีเครื่องมือภายนอกในการจัดการแพ็คเกจ ไม่จำเป็นต้องสร้างการเชื่อมต่ออินเทอร์เน็ต สร้างได้เร็วขึ้น (ไม่มีการตรวจสอบแพ็คเกจ) สภาพแวดล้อมที่เรียบง่าย (ต้องการความรู้น้อยกว่า) ข้อดีที่ฉันเห็นกับผู้จัดการบรรจุภัณฑ์: ช่วยต้นไม้ที่พึ่งพาได้ซับซ้อน (และสามารถจัดการดาวน์โหลดการอ้างอิงพร้อมกับการพึ่งพาทั้งหมด) ช่วยตรวจสอบว่ามีเวอร์ชั่นใหม่หรือไม่ ดูเหมือนว่าอุตสาหกรรมได้ตัดสินใจที่จะทำตามเส้นทางผู้จัดการบรรจุภัณฑ์สำหรับเกือบทุกอย่างที่สร้างขึ้นในวันนี้ แล้วฉันจะพลาดอะไร

3
Folder-by-type หรือ Folder-by-feature
ฉันใช้ประโยชน์จากคู่มือสไตล์ AngularJS ภายในคู่มือนี้มีรูปแบบที่เรียกว่าfolder-by-featureแทนที่จะเป็นfolder-by-typeและฉันอยากรู้จริง ๆ แล้วว่าอะไรคือวิธีที่ดีที่สุด (ในตัวอย่างนี้สำหรับ Java) สมมติว่าฉันมีแอปพลิเคชันที่ฉันสามารถดึงผู้ใช้และสัตว์เลี้ยงโดยใช้บริการตัวควบคุมที่เก็บและวัตถุโดเมนของหลักสูตร ด้วยรูปแบบโฟลเดอร์โดย -..... เรามีสองตัวเลือกสำหรับโครงสร้างบรรจุภัณฑ์ของเรา: 1. โฟลเดอร์ตามประเภท com.example ├── domain │ ├── User.java │ └── Pet.java ├── controllers │ ├── UserController.java │ └── PetController.java ├── repositories │ ├── UserRepository.java │ └── PetRepository.java ├── services │ ├── UserService.java │ └── PetService.java │ // and everything …

5
มาตรฐานสำหรับการบรรจุซอร์สโค้ด Linux กลายเป็น. tar.gz เมื่อใด
เมื่อเรียกดูโปรเจ็กต์โอเพนซอร์สที่พัฒนาเป็นหลักสำหรับระบบ Linux และการดาวน์โหลดแพ็คเกจล่าสุดซอร์สโค้ดจะถูกเก็บไว้ในไฟล์. tar.gz หรือ. tar.bz2 เสมอ มีเหตุผลใดบ้างสำหรับการใช้. tar.gz หรือ. tar.bz2 แทนที่จะเป็น. zip หรือ. rar หรืออัลกอริทึมการบีบอัดอื่น ๆ (หรือปล่อยให้ไม่มีการบีบอัดหากโครงการมีขนาดเล็ก)

3
รับข้อมูลสิทธิ์ใช้งานสำหรับแพ็คเกจ NuGet ที่ใช้แล้วทั้งหมด
เพื่อให้บ้านของเราเป็นไปตามลำดับฉันต้องการรวบรวมใบอนุญาตโดยอัตโนมัติสำหรับการอ้างอิงโครงการในเอกสารของเราแทนที่จะต้องเพิ่มด้วยตนเอง ไม่มีใครรู้วิธีที่ง่ายในการสำรวจชุดของไฟล์ CSPROJ โดยทางโปรแกรมและแยกข้อมูลใบอนุญาตสำหรับแพ็คเกจอ้างอิงเป็นลิงค์หรือสตริง?

1
การกระจายไฟล์หลามเดียว: โมดูลหรือแพ็คเกจ?
สมมติว่าฉันมีฟังก์ชั่นหลามที่มีประโยชน์หรือคลาส (หรืออะไรก็ตาม) ที่เรียกว่าuseful_thingซึ่งมีอยู่ในไฟล์เดียว มีสองวิธีที่จำเป็นในการจัดระเบียบต้นไม้ต้นกำเนิด วิธีแรกใช้โมดูลเดียว: - setup.py - README.rst - ...etc... - foo.py ที่กำหนดไว้ในuseful_thing foo.pyกลยุทธ์ที่สองคือการทำแพคเกจ: - setup.py - README.rst - ...etc... - foo |-module.py |-__init__.py ที่กำหนดไว้ในuseful_thing module.pyในกรณีแพคเกจ__init__.pyจะมีลักษณะเช่นนี้ from foo.module import useful_thing from foo import useful_thingเพื่อที่ว่าในทั้งสองกรณีที่คุณสามารถทำได้ คำถาม:วิธีใดที่เป็นที่ต้องการและทำไม แก้ไข: เนื่องจากผู้ใช้ริ้นกล่าวว่าคำถามนี้เกิดขึ้นไม่ดีฉันจะเพิ่มว่าการสอนบรรจุภัณฑ์งูใหญ่อย่างเป็นทางการดูเหมือนจะไม่แสดงความคิดเห็นว่าวิธีการใดที่อธิบายไว้ข้างต้นเป็นวิธีที่ต้องการ ฉันไม่ได้ให้รายการข้อดีข้อเสียส่วนตัวอย่างชัดเจนเพราะฉันสนใจว่ามีวิธีที่ชุมชนต้องการหรือไม่ไม่สร้างการอภิปรายข้อดี / ข้อเสีย :)

2
เหตุใดแพ็คเกจและโมดูลจึงเป็นแนวคิดแยกต่างหากใน Java 9
Java 9 จะมีโมดูลเพิ่มเติมจากแพ็คเกจ ภาษามักจะมีอย่างใดอย่างหนึ่ง และโปรแกรมเมอร์ส่วนใหญ่รับรู้ศัพท์สองคำว่าเป็นคำพ้องความหมาย โมดูลถูกสร้างขึ้นบนบรรจุภัณฑ์โดยถือเป็นโมดูลดั้งเดิม รูปแบบคอมโพสิตแนะนำให้รักษาแบบดั้งเดิมและคอมโพสิตอย่างสม่ำเสมอ สิ่งที่ไม่ดีจะเกิดขึ้น ตัวอย่างเช่นดูโครงการ Valhalla ที่พวกเขาพยายามติดตั้ง supertype ทั่วไปสำหรับประเภทดั้งเดิม (ค่า) และประเภทการอ้างอิง โมดูลและแพคเกจเป็นตัวแทนของความคิดแยกความหมายหรือไม่ หมายความว่ามีเหตุผลที่จะต้องมีทั้งภาษาใด ๆ (แยกความกังวล) หรือ Java จะต้องมีทั้งคู่เป็นส่วยให้เข้ากันได้ย้อนหลัง? ทำไมแนะนำแนวคิดใหม่แทนที่จะเพิ่มแนวคิดที่มีอยู่ JSR 376 : "Java ระบบโมดูลแพลตฟอร์ม" ดำเนินการภายในโครงการจิ๊กซอว์ ตามSOTMS โมดูลคือชุดของโค้ดและข้อมูลที่อธิบายตนเอง รหัสของมันถูกจัดระเบียบเป็นชุดของแพคเกจที่ประกอบด้วยชนิดเช่นคลาส Java และอินเตอร์เฟส ข้อมูลรวมถึงทรัพยากรและข้อมูลคงที่ประเภทอื่น ๆ JLS ระมัดระวังหลีกเลี่ยงการกำหนดสิ่งที่เป็นแพคเกจ จากวิกิพีเดีย : แพคเกจ Java เป็นเทคนิคสำหรับการจัดคลาส Java เป็นเนมสเปซที่คล้ายกับโมดูลของ Modula โดยให้การเขียนโปรแกรมแบบแยกส่วนใน Java ฉันรู้ว่าการอ้างถึงวิกิพีเดียเป็นการปฏิบัติที่ไม่ดี แต่สะท้อนถึงความเข้าใจร่วมกัน …

3
ชื่อแพ็กเกจใดที่จะเลือกสำหรับโครงการ Java ขนาดเล็กแบบโอเพ่นซอร์ส [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว ฉันต้องการเผยแพร่ไลบรารีโอเพนซอร์สขนาดเล็กใน Java ฉันสงสัยว่าฉันควรเลือกชื่อแพ็คเกจอะไร ฉันไม่ใช่ บริษัท และฉันไม่มีโดเมนที่ฉันสามารถใช้เป็นพื้นฐานสำหรับการตั้งชื่อแพ็คเกจตามข้อกำหนดการตั้งชื่อได้ ยังฉันต้องการที่จะปฏิบัติตามอนุสัญญาการตั้งชื่อเพื่อป้องกันความขัดแย้งโดยไม่ตั้งใจและเพื่อให้สิ่งต่าง ๆ มาตรฐาน

4
ชื่อแพคเกจที่เหมาะสมมีความหมายมากกว่า `ใช้ 'สำหรับสิ่งต่อไปนี้?
ในฐานะชาวฟางพิจารณาแพคเกจjava.utilมันเป็นพื้นทิ้งสำหรับชั้นเรียนต่างๆที่ในกรณีส่วนใหญ่ไม่แบ่งปันอะไรกันมากกว่าคนที่ทำให้พวกเขามีขี้เกียจหรือไม่มีปฏิภาณที่จะเกิดขึ้นกับชื่อแพคเกจที่ถูกต้องเชิงความหมายสำหรับชั้นเรียนของพวกเขา เป็นตัวอย่างหนึ่ง แต่ให้ชั้นเรียนUUIDชื่อแพคเกจที่ถูกต้องทางความหมายสำหรับคลาสนั้นคืออะไร? ฉันกำลังทำงานUUIDเพื่อทำให้ชั้นเรียนของฉันมีน้ำหนักเบาขึ้น ฉันไม่ต้องการใช้me.myproject.util.UUIDสำหรับชื่อแพ็คเกจ ผมถือว่าแต่ที่ไม่ได้หมายความความหมายของการใช้me.myproject.rfc4122.UUIDUUID ฉันก็คิดเช่นกันme.myproject.uuid.UUIDแต่ฉันไม่ชอบคำซ้ำซากในที่นั้นแม้ว่าจะเป็นวิธีที่นิยมใน Python ที่จะนำคลาสในโมดูลที่มีชื่อเดียวกันและpackagesใน Java นั้นไม่เทียบเท่ากับmodulesใน Python ฉันยังพิจารณาme.myproject.UUIDแต่ปฏิเสธเพราะฉันไม่ต้องการสร้างมลภาวะเป็นส่วนหนึ่งของเนมสเปซกับสิ่งที่ไม่เกี่ยวข้อง นี่แค่ยกระดับปัญหาขึ้น ฉันพิจารณาด้วยเช่นกันme.myproject.lib.UUIDแต่นี่ไม่มีความหมายเชิงความหมายมากไปกว่า.utilและเพียงแค่เปลี่ยนชื่อปัญหา semanticsสาขาวิชาภาษาศาสตร์และตรรกะที่เกี่ยวข้องกับความหมาย

1
แนวทางที่ดีสำหรับการทำเว็บแอพพลิเคชัน PHP สำหรับบรรจุภัณฑ์ Debian
เว็บแอปพลิเคชั่น PHP หลายรุ่นใช้สำหรับติดตั้งและอัปเกรด: ยกเลิกการ tar ลูก tar แหล่งที่มา ชี้ Apache ที่แหล่งที่มา นำทางเว็บเบราว์เซอร์ไปที่หน้าแรก ดำเนินการผ่านหน้าเว็บหลายหน้าของการตั้งค่า (เช่นการตรวจสอบการมีอยู่ของห้องสมุดการขอข้อมูลการเชื่อมต่อฐานข้อมูลการสร้างหรืออัพเดทคีมาฐานข้อมูล ฯลฯ ) ผู้ใช้เปลี่ยนชื่อinstall/ไดเรกทอรีเป็นอย่างอื่นเพื่อให้แอปพลิเคชันรู้ว่าติดตั้งแล้ว ฉันไม่เห็นวิธี (ง่ายๆ) ในการสร้างแพ็คเกจ Debian จากสิ่งนี้โดยไม่ทำให้ผู้ใช้ติดตั้งแพคเกจทำตามขั้นตอนด้วยตนเองหลายขั้นตอนข้างต้น โปรดทราบว่าฉันไม่ใช่นักพัฒนาในแอปพลิเคชันดังนั้นฉันไม่ได้อยู่ในฐานะที่จะทำการเปลี่ยนแปลงโดยตรงกับวิธีการติดตั้งแอปพลิเคชัน วิธีการทั่วไปในการทำบรรจุภัณฑ์ของแอพพลิเคชั่นดังกล่าวคืออะไร?

3
จุดประสงค์ของการตั้งชื่อแพ็คเกจของ Java คืออะไร?
ฉันไม่เข้าใจว่าทำไม Java จึงใช้ชื่อโดเมน (อาจเป็นสมมุติฐาน) กลับด้านในขณะที่ส่วนใหญ่ไม่มีการเชื่อมต่อระหว่างชื่อโดเมนที่บางคนใช้และผลิตภัณฑ์ที่พวกเขามี นักพัฒนาจำนวนมากไม่มีแม้แต่โดเมนใด ๆ อะไรคือสาเหตุของอนุสัญญาการตั้งชื่อนี้ถ้ามี?
14 java  packages 

4
ข้อดีของเนมสเปซ / แพ็คเกจ
ภาษาการเขียนโปรแกรมบางภาษา (เช่น Java และ C ++) มีคุณสมบัติภาษาที่เรียกว่า "แพ็คเกจ" หรือ "namespaces" การมีเนมสเปซเป็นประโยชน์จริง ๆ อย่างไร เป็นไปได้ที่จะทำเครื่องหมายฟังก์ชั่นและคลาสว่าเป็นของห้องสมุดบางแห่งโดยไม่ใช้คุณสมบัติภาษาเช่น SDL ทำ (เช่นSDL_BlitSurface()) เนมสเปซไม่มีประโยชน์เพียงพอที่จะคุ้มค่าหรือไม่? มันมีประโยชน์ในห้องสมุด แต่ไม่ใช่ในแอพพลิเคชัน มีประโยชน์ทุกที่ยกเว้นในโครงการขนาดเล็กหรือไม่? คิด?

3
หนึ่งควรจัดการค่าคงที่ในหลายภาษาได้อย่างไร?
ฉันมีสถานการณ์ที่ฉันสนับสนุนสิ่งที่เป็นหน้าที่ของไลบรารีเดียวกันในหลายภาษา มักจะมีค่าคงที่ที่ต้องใช้ร่วมกันระหว่างเหล่านี้ (ตัวอย่างเช่นคีย์ชื่อเขตข้อมูล json หรือรหัสข้อผิดพลาด) วิธีที่ฉันทำอยู่ในขณะนี้คือการให้รหัสกำหนดค่าคงที่ในแต่ละภาษา ปัญหาเกิดขึ้นในการบำรุงรักษา หากฉันเพิ่มรหัสข้อผิดพลาดใหม่ฉันต้องอัปเดตในทุกไลบรารีด้วยตนเอง ในขณะนี้ใช้ได้สำหรับบางมันกลายเป็นน่าเบื่อถ้าฉันพูด 5 sdks เพื่อปรับปรุง มันคงจะดีถ้ามีแหล่งความจริงแหล่งเดียวสำหรับสิ่งเหล่านี้เช่นกัน ฉันคิดเกี่ยวกับการจัดเรียงของการตั้งค่าเหมือนบางไฟล์ แต่แล้วก็จะต้องมีการรวมอยู่ในทุกแพคเกจการใช้งานซึ่งจะเพิ่มความซับซ้อนในการสร้างกระบวนการ / การเปิดตัวของเรา มีวิธีที่ดีกว่าในการจัดการค่าคงที่ซึ่งใช้ร่วมกันระหว่างหลายภาษาหรือไม่
13 design  packages 

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.