PYX: ก้าวถัดไปของการแพ็กเกจจิ้ง Python
(astral.sh)- pyx คือ รีจิสทรีแพ็กเกจแบบเนทีฟสำหรับ Python ที่สร้างโดยทีมพัฒนา uv ซึ่งช่วยเพิ่มความเร็วในการติดตั้งจาก PyPI, PyTorch และซอร์สภายในองค์กรได้ สูงสุด 10 เท่า
- ไม่ได้จำกัดอยู่แค่ขอบเขตของรีจิสทรีแพ็กเกจแบบเดิม แต่ยังมีความสามารถด้าน ความเร็ว ความปลอดภัย และการรับรู้ GPU พร้อมรองรับทั้งแพ็กเกจภายในและซอร์สสาธารณะอย่าง PyPI และ PyTorch
- มี URL ดัชนีเฉพาะทาง ที่สามารถกรองได้ตามเกณฑ์อย่างความนิยมของแพ็กเกจ เวลาที่สร้าง และการมีช่องโหว่หรือไม่ เพื่อเสริมความปลอดภัยและการปฏิบัติตามข้อกำหนด
- รองรับ มาตรฐานสมัยใหม่ ที่ออกแบบมาสำหรับ Python และมี การผสานรวมโดยตรงกับ uv ทำให้ยืนยันตัวตนและใช้งานได้โดยไม่ต้องตั้งค่า
- แก้ปัญหาสำคัญใน สภาพแวดล้อมระดับองค์กร เช่น การบิลด์ซ้ำภายในทีม ความยากในการติดตั้ง PyTorch·CUDA บิลด์พัง และความไม่สะดวกด้านการยืนยันตัวตน ด้วยการผสานรวมฝั่งเซิร์ฟเวอร์และไคลเอนต์
- ด้วย ความสามารถในการรับรู้ GPU จึงสามารถให้เวอร์ชัน prebuilt ของ PyTorch, vLLM, FlashAttention, DeepSpeed ฯลฯ ที่เหมาะกับฮาร์ดแวร์ พร้อมเมทาดาทาที่สอดคล้องกันและการตั้งค่าที่เหมาะสมที่สุด
- มอบประสิทธิภาพที่เหนือกว่ารีจิสทรีส่วนตัวอื่น ๆ อย่างชัดเจน ผ่านอาร์ติแฟกต์ที่ปรับแต่งมาแล้วและ uv native metadata API
วิสัยทัศน์และที่มาของ Astral
- Astral เป็นบริษัทที่สร้าง เครื่องมือพัฒนาประสิทธิภาพสูง สำหรับระบบนิเวศ Python และเป็นที่รู้จักดีจาก Ruff (linter·formatter) และ uv (package manager)
- จุดเริ่มต้นของการก่อตั้งคือ แม้ Python จะเป็นภาษาโปรแกรมที่ได้รับความนิยมมากที่สุดในโลก แต่กลับ ยังไม่ได้รับการสนับสนุนด้าน tooling อย่างเพียงพอ
- ปัจจุบันชุดเครื่องมือของ Astral มียอดติดตั้งมากกว่า 100 ล้านครั้งต่อเดือน และ uv รองรับคำขอมากกว่า 500 ล้านครั้งต่อวัน โดยกำลังเติบโตอย่างรวดเร็ว
- เป้าหมายคือทำให้ Python เป็น ระบบนิเวศการเขียนโปรแกรมที่มีประสิทธิภาพสูงที่สุด และเพื่อสิ่งนั้น บริษัทต้องการสร้าง Python cloud ที่ก้าวข้ามจากเครื่องมือฝั่งไคลเอนต์
แนะนำ pyx
- pyx คือ รีจิสทรีแพ็กเกจแบบเนทีฟสำหรับ Python ที่ออกแบบมาเป็นแบ็กเอนด์ที่ปรับแต่งมาแล้วสำหรับ uv
- สามารถโฮสต์แพ็กเกจภายในองค์กรได้
- ทำหน้าที่เป็นฟรอนต์เอนด์ที่เร่งความเร็วและตั้งค่าได้สำหรับซอร์สสาธารณะ เช่น ดัชนีของ PyPI และ PyTorch
- คุณสมบัติหลัก
- ความเร็วในการติดตั้งสูง : ปรับแต่งการติดตั้งและการบิลด์แพ็กเกจให้เหมาะสม
- ใช้อาร์ติแฟกต์ที่ปรับแต่งแล้วและ uv native metadata API เมื่อติดตั้งแพ็กเกจจาก PyPI, PyTorch และซอร์ส private ภายใน
- เร็วกว่ารีจิสทรีส่วนตัวอื่นได้สูงสุด 10 เท่า
- เสริมความปลอดภัยและการปฏิบัติตามข้อกำหนด : ลดความเสี่ยงด้วยความเข้าใจด้าน dependency และ supply chain
- สามารถสร้าง URL ดัชนีเฉพาะทางเพื่อใช้กรองแพ็กเกจได้
- ควบคุมการเข้าถึงแพ็กเกจตามเกณฑ์ เช่น ความนิยม อายุของรีลีส และสถานะช่องโหว่
- รับประกันการบิลด์ที่ทำซ้ำได้บนฝั่งเซิร์ฟเวอร์
- รองรับมาตรฐานล่าสุด
- รองรับมาตรฐานและเวิร์กโฟลว์ด้าน packaging ล่าสุดที่ออกแบบมาสำหรับ Python
- ผสานรวมกับ uv โดยตรง จึงยืนยันตัวตนและใช้งานได้อย่างราบรื่นโดยไม่ต้องตั้งค่าเพิ่มเติม
- การแจกจ่ายแพ็กเกจที่รับรู้ GPU : ทำให้การบิลด์และแจกจ่ายที่เกี่ยวข้องกับ CUDA·PyTorch ง่ายขึ้น
- มี prebuilt แบบปรับให้เหมาะกับ GPU สำหรับไลบรารีอย่าง PyTorch, vLLM, FlashAttention, DeepSpeed
- คงการตั้งค่าที่เหมาะสมที่สุดตามฮาร์ดแวร์และรักษาเมทาดาทาให้สอดคล้องกัน
- ความเร็วในการติดตั้งสูง : ปรับแต่งการติดตั้งและการบิลด์แพ็กเกจให้เหมาะสม
ปัญหาที่ต้องการแก้
- ความยากในการติดตั้งไลบรารีที่เกี่ยวข้องกับ GPU เช่น PyTorch·CUDA·FlashAttention·DeepSpeed
- การสิ้นเปลืองทรัพยากรจากการบิลด์แพ็กเกจเดียวกันซ้ำภายในทีม
- ข้อผิดพลาดในการบิลด์จากการอัปเดต setuptools
- ความไม่สะดวกของกระบวนการยืนยันตัวตนกับรีจิสทรีภายใน
กลยุทธ์การผสานรวมเซิร์ฟเวอร์-ไคลเอนต์
- แก้ปัญหาข้างต้นโดยตรงด้วยการผสานรวมแนวดิ่งระหว่าง uv (ไคลเอนต์) และ pyx (เซิร์ฟเวอร์)
- สามารถใช้ uv โดยไม่มี pyx หรือใช้ pyx โดยไม่มี uv ก็ได้ แต่จะมอบ ประสบการณ์ที่ดีที่สุดเมื่อใช้ร่วมกัน
- ด้วยการผสานรวมเชิงลึกกับเครื่องมือโอเพนซอร์ส จึงสามารถสร้างประสบการณ์การพัฒนาที่ก่อนหน้านี้ทำไม่ได้
โมเดลธุรกิจ
- เครื่องมือของ Astral อย่าง uv, Ruff, ty จะยังคงเป็น ฟรี โอเพนซอร์ส และใช้ไลเซนส์แบบ permissive ตลอดไป
- แทนที่จะคิดเงินจากเครื่องมือเหล่านั้น บริษัทจะให้บริการ โฮสติ้งแบบเสียเงิน เช่น pyx เพื่อตอบโจทย์ความต้องการด้านโครงสร้างพื้นฐานใน “ขั้นถัดไป”
สถานะปัจจุบันและแผนในอนาคต
- ขณะนี้กำลังใช้งานร่วมกับ พาร์ตเนอร์ระยะแรก เช่น Ramp, Intercom และ fal
- จะรักษาวงจรรับฟีดแบ็กที่รวดเร็วผ่าน open build ไปจนกว่าจะถึง GA (general availability)
- เชิญชวนทีมและผู้สนใจติดต่อเข้ามา
4 ความคิดเห็น
ผมอ่านไปพลางคิดไปว่า บริษัทนี้จะหารายได้อย่างไร สุดท้ายก็คงมีแผนจะให้บริการ pyx แบบเสียเงินสินะ
พูดว่าปัญหาทุกอย่างของการแพ็กเกจ Python ถูกแก้หมดแล้วนี่ก็ตลกดีนะ
มันไม่ใช่ว่าแก้ได้แล้ว แค่เก็บๆ ให้พอใช้งานต่อไปได้ไม่ใช่เหรอ 555
Python เป็นภาษาหลักที่ใช้กันทั่วโลก แต่ความจริงก็คือสภาพแวดล้อมของมันรกมากจริงๆ
ในคอมเมนต์บน Hacker News มีคนกังวลว่า 'บริษัท' จะเข้ามามีบทบาท แต่กลับไม่ได้นึกเลยว่าไม่มีใครสนใจอะไรเลยจนกว่าบริษัทจะเข้ามา สุดท้ายสถานการณ์มันถึงได้กลายเป็นแบบนี้
FYI: มีการอ้างคำพูดของใครบางคนในคอมเมนต์ของ Hacker News
ความคิดเห็นบน Hacker News
น่าจะแชร์บทความบล็อกที่มีประโยชน์กว่านี้ https://astral.sh/blog/introducing-pyx
ผมคิดว่าปัญหาเรื่อง Python packaging ทั้งหมดถูกแก้ไปหมดแล้ว บทเรียนที่ได้จากตรงนี้คือ ไม่มีโซลูชันเดียวที่เหมาะกับทุกปัญหา การผูกโยงกับบริษัทที่มีเงิน VC หนุนหลังมากขึ้น หรือพึ่งพาโครงสร้างพื้นฐานของพวกเขา เป็นความเสี่ยงใหญ่ต่อชุมชน FOSS เสมอ
ผมเริ่มจากการถูกบอกให้ใช้ pip แต่ทั้งช้าและมีปัญหาบ่อย เลยเปลี่ยนไปใช้ virtualenv ซึ่งแก้ได้แค่บางส่วน จากนั้นก็ใช้ conda ซึ่งบางทีก็ใช้งานได้ แต่ทำ shell profile พังเละ และก็มักมีปัญหาเวอร์ชันแพ็กเกจตีกัน ต่อมาก็มีคนแนะนำ pipenv ตอนแรกก็ดี แต่พอการพัฒนาถูกปล่อยทิ้งและมีการเปลี่ยนคนดูแล มันก็พังบ่อยในเวอร์ชันใหม่ หลังจากนั้นก็มีคนแนะนำ poetry แต่ช้าเกินจะใช้งานได้ สุดท้ายเลยย้อนกลับไปใช้ pip กับ
venvที่มีมาให้ในตัว แต่ก็เจอปัญหาเดิมอีก แถมฟีเจอร์ก็น้อยกว่าเดิมด้วย เลยย้ายไป uv ซึ่งอย่างน้อยก็พอทำงานได้ แต่ dependency ที่ผมต้องใช้มีวิธี build และ packaging ต่างกันตามระบบปฏิบัติการและ GPU จนเพื่อนร่วมงานของผมติดตั้งโปรเจกต์นี้ลงบนแล็ปท็อปตัวเองไม่ได้ด้วยซ้ำ ดีจังเลยที่ปัญหา Python packaging ถูก “แก้หมดแล้ว”การบอกว่า “ปัญหาเรื่อง Python packaging ทั้งหมดถูกแก้ไปหมดแล้ว” ฟังดูเป็นคำพูดของคนที่ไม่รู้จริงหรือไม่ก็ไม่เข้าใจอะไรเลย Python ยังไม่มีวิธีจัดการ native dependency ข้ามหลายแพลตฟอร์มได้อย่างเสถียรอยู่ดี pip กับ setuptools ไม่ควรเป็นจุดสูงสุดสุดท้ายของ ecosystem นี้
ผมเห็นด้วยกับความกังวลนั้น แต่หลังจากใช้ uv แล้วผมประหยัดเวลาไปมหาศาล เลยคงใช้ต่อไปจนกว่าด้านแย่ของเงิน VC จะทำให้มันพังจริง ๆ ถึงตอนนั้นก็หวังว่าชุมชนจะรวมตัวกันไปในทิศทางเดียวได้
ช่วง 3 ชั่วโมงที่ผ่านมาเพิ่งสู้กับ python และ debian จนเดือดกับ ecosystem ของ Python มาก มันไม่ได้ถูกแก้อะไรเลย ใน Debian เหมือนจะแนะนำให้ใช้แต่
venvแต่แพ็กเกจที่ติดตั้งในvenvมักเป็นสิ่งที่เครื่องมืออย่าง cmake หาไม่เจอ ยังมีแพ็กเกจจาก apt-get ด้วย และบางเครื่องมือก็หาเจอแค่นั้น ในขณะที่บางตัวกลับหาไม่เจออีก ชื่อแพ็กเกจก็ไม่สม่ำเสมอ คอนโซลของผมแนะนำpipxแต่ประสบการณ์ใช้งานก็คล้าย ๆ เดิม แถมซากจากยุค python 2 vs 3 ก็ยังหลงเหลืออยู่ ทำให้การค้นหาแพ็กเกจล้มเหลวบ่อยเพียงเพราะมีหรือไม่มีเลขเวอร์ชันในชื่อ ถึงจะไม่รู้ว่า c++headerparser คืออะไร แต่สุดท้ายมันทำให้ผมยิ่งมั่นใจว่าควรเอา Python ออกจาก build tree ไปเลยแล้วปล่อยให้กลายเป็นประวัติศาสตร์เสียมาใหม่หรือเปล่า? ขอแนะนำให้ลองดื่ม Kool Aid แก้วนี้ดู อย่าไปสนใจโลโก้ "MongoDB" ที่ติดอยู่บนแก้ว มันของเก่าแล้ว
ผมเคยเชื่อใจผลิตภัณฑ์โอเพนซอร์สมาหลายครั้งแล้วก็เจ็บตัวซ้ำ ๆ ได้ยินคำสัญญาแบบนี้มานับไม่ถ้วน สุดท้ายวันหนึ่งก็ถูกซื้อกิจการ แล้วเอกสาร, issue, PR ที่สะสมมาหลายปีก็ถูกเก็บกวาดแทบไม่มีการเตือนล่วงหน้า จากนั้นบริษัทใหม่ก็ออกผลิตภัณฑ์เชิงพาณิชย์อะไรบางอย่างมา แต่ฟีเจอร์หลักที่ผมใช้อยู่กลับหายไป
แม้จะเข้าใจความกังวลนี้ แต่อยากเน้นว่า pyx เป็นผลิตภัณฑ์ที่แยกออกมาเชิงกลยุทธ์จากเครื่องมือเดิมของ Astral แตกต่างจากของเดิมที่มีอยู่ ในประกาศอย่างเป็นทางการก็ระบุว่า “pyx คือการทำให้กลยุทธ์ของ Astral เป็นจริง และเครื่องมือของ Astral จะยังคงฟรี เป็นโอเพนซอร์ส และอยู่ภายใต้ไลเซนส์ที่เปิดกว้างมากตลอดไป” สิ่งที่เราตั้งเป้าคือ ลดความกังวลด้วยการสร้างสินค้าที่แยกออกมาและยั่งยืนเชิงพาณิชย์ แทนการหารายได้จากเครื่องมือโอเพนซอร์สโดยตรง
เป็นความกังวลที่เข้าใจได้อย่างเต็มที่ แต่ผมคิดว่าชื่อเสียงและผลงานของ Astral นั้นยอดเยี่ยมจริง ๆ เลยแปลกใจที่ HN มีปฏิกิริยาอย่างระมัดระวังแบบนี้ ผมเขียน Python มามากกว่าสิบปีแล้ว และถ้า Astral ทำอะไรสักอย่าง ผมก็มักจะตั้งตารอเสมอ
ถ้ามันเป็นฟีเจอร์ที่มีคุณค่าจริง ๆ ผมคิดว่ามันคงถูกรวมเข้าไปใน pip แล้ว
เห็นด้วยมากกับประเด็นที่ว่าการติดตั้ง PyTorch, CUDA หรือ FlashAttention, DeepSpeed พวกนี้มันยาก บน Windows (รวมถึง WSL) ยังมีปัญหาที่บางแพ็กเกจต้องการคอมไพเลอร์จาก Visual Studio เวอร์ชันเก่ามาก จนต้องไปไล่หาพาธดาวน์โหลดเองแบบน่ารำคาญ หวังว่าจะได้ประสบการณ์นักพัฒนาที่ดีกว่านี้
จริง ๆ แล้ว WSL แทบจะเหมือน Linux อยู่แล้ว เพราะงั้นเวอร์ชันของคอมไพเลอร์ Visual Studio ไม่น่าจะสำคัญมาก ไบนารีของ WSL ทั้งหมดถูก build ด้วย toolchain ฝั่ง Linux บน Windows เอง
libcก็เสถียรมากแล้วตั้งแต่ Win10 เป็นต้นมา ไบนารีที่ build ด้วย VC++ 2015 ขึ้นไปยังคงรักษาความเข้ากันได้ของ C-ABI ระหว่างกัน จะต้องใช้คอมไพเลอร์เก่าจริง ๆ ก็เฉพาะกรณีที่ภาษาหรือฟีเจอร์บางอย่างคอมไพเลอร์รุ่นเก่าไม่รองรับ หรือพยายามส่งผ่านอ็อบเจ็กต์ C++ ข้าม ABI โดยตรง ซึ่งเป็นเคสที่พบไม่บ่อยเรื่องแบบนี้แหละที่ครั้งหนึ่งทำให้ผมเลิกยุ่งกับ Ruby ไปเลยเพราะ Rails เวลาดูวิดีโอ Ruby ก็เห็นทุกคนพัฒนาอย่างมีความสุข น่าอิจฉาอยู่หรอก แต่ในสภาพแวดล้อมของผม ถ้าจะตั้งค่า dev environment ให้ได้ต้องใช้ DigitalOcean droplet เท่านั้น และก็มักพังเพราะ error ตอนคอมไพล์สำหรับ Rails อยู่เรื่อย ๆ ราวปี 2012 ผมก็อยากเกาะกระแส Rails บ้าง แต่กระบวนการตั้งค่า/ติดตั้งมันเหมือนฝันร้ายตลอด เลยย้ายมาที่ Python ซึ่งช่วงแรกก็ดี แต่ทุกวันนี้ถ้าเกี่ยวกับ AI หรือ CUDA บางทีกลายเป็นว่ามันนรกการติดตั้งจนรู้สึกว่าตาม shell script ของคนอื่นไปเลยยังจะง่ายกว่า
ผมคิดว่านี่แหละคือทิศทางที่ Python packaging ควรไปสำหรับ workflow ที่เน้น GPU โดยเฉพาะมีอยู่สองอย่างที่น่าตื่นเต้น อย่างแรกคือการมีดัชนีที่ผ่านการตรวจสอบความเข้ากันได้แยกตาม accelerator (เช่น CUDA/ROCm/CPU แต่ละแบบ) เพื่อให้ไม่ต้องมาถกกันเรื่องเมทริกซ์ torch/cu* อีก อย่างที่สองคือทำให้ client query metadata ได้เพื่อขนานการติดตั้ง ถ้า pyx ช่วยลด “ลูปลองผิดลองถูกของ pip” ในสภาพแวดล้อม ML ได้ พร้อมทั้งรองรับ build สำหรับฮาร์ดแวร์เป้าหมายและให้แฮชที่คาดเดาได้ เวลาที่ใช้ไปกับการจัดสภาพแวดล้อมจะลดลงมาก อีกทั้งโมเดลที่ยังคงเปิดซอร์สเครื่องมือไว้ แล้วหารายได้จากบริการโฮสต์ ก็เป็นสัญญาณบวกต่อการสร้างความเชื่อมั่นด้วย ผมสงสัยว่า pyx จะรองรับการตรวจสอบซัพพลายเชนอย่าง dependency graph, reverse dependency (
what breaks if X→Y?), SBOM/หลักฐานลายเซ็นพวกนี้ด้วยหรือเปล่าครั้งหนึ่งระบบปฏิบัติการเคยถือเป็นเรื่องปกติที่จะมีคอมไพเลอร์ติดมาให้ในตัว
เมื่อก่อนเหตุผลชี้ขาดที่ผมเลือกใช้ anaconda ก็เพราะสภาพแวดล้อมแบบนี้นี่แหละ
มีการเล่นมุกว่า “เดี๋ยวจะมีมาตรฐาน Python packaging ที่แข่งขันกัน 14 แบบ” จริง ๆ 14 นี่พูดเล่น เพราะเกินกว่านั้นไปนานแล้ว
ผมคิดว่า Python packaging คือส่วนที่ขัดกับ Zen ของ Python มากที่สุดใน Python
เมื่อเดือนกันยายนปีที่แล้ว Charlie เคยเปิดเผยบน Mastodon ว่ากำลังคิดโมเดลธุรกิจนี้อยู่ https://hachyderm.io/@charliermarsh/113103564055291456
ผมสงสัยว่าคำว่า GPU-aware registry ในที่นี้หมายถึงอะไรแบบเป็นรูปธรรม uv จะตรวจสเปก GPU ของผม แล้วไปหยิบชุดแพ็กเกจที่เหมาะจาก Pyx มาให้โดยอัตโนมัติหรือเปล่า? ถ้านี่เป็น private registry แบบเสียเงินสำหรับลูกค้าองค์กร บริษัทจะสามารถเปิด registry แบบ public instance ให้คนภายนอกใช้ได้ด้วยไหม? หรือพูดอีกแบบคือ ถ้าผมเป็น vendor ผมจะสามารถรัน Pyx registry แบบเสียเงินสำหรับแพ็กเกจของตัวเอง แล้วให้ลูกค้าใช้เป็น entrypoint ได้ไหม
uv pip install --torch-backend=auto torchจะติดตั้ง PyTorch เวอร์ชันที่เหมาะกับ GPU ของผมโดยอัตโนมัติจากดัชนีของ PyTorch pyx คือโมเดลที่ขยายแนวคิดนี้ออกไปอีก ไม่ใช่แค่ PyTorch แต่มีดัชนีที่คัดสรรมาอย่างดีสำหรับแต่ละ hardware accelerator โดยในดัชนีจะมีผลลัพธ์ที่ build แล้วสำหรับแพ็กเกจ เวอร์ชัน เวอร์ชัน Python เวอร์ชัน PyTorch ฯลฯ พร้อม metadata ที่สอดคล้องกัน นั่นหมายความว่าเมื่อใช้ pyx ก็จะรับ build ที่เหมาะกับปัญหาด้านความเข้ากันได้/ความเร็วได้ง่าย และ client ของ uv ก็จะช่วยหา pyx index ที่เหมาะสมให้อัตโนมัติด้วย (ส่วนนี้มีการทำงานพื้นฐานอยู่แล้วไม่ว่าจะใช้ pyx หรือไม่ แต่ถ้าเป็น pyx จะทรงพลังยิ่งกว่า) อีกทั้งความสามารถที่ vendor จะรัน registry แบบ pyx สำหรับแพ็กเกจของตัวเองแล้วให้ลูกค้าใช้เป็นทางเข้า ยังไม่ได้รองรับอย่างเป็นทางการในตอนนี้ แต่ถ้าสนใจจริงก็สามารถติดต่อมาคุยรายละเอียดได้ผมพูดไว้ตั้งแต่ไม่กี่สัปดาห์ก่อนแล้วว่า สักวัน Astral จะต้องมีกลยุทธ์หารายได้ และผมคาดว่าหัวใจจะไม่ใช่ Uv แต่จะเป็นอะไรในลักษณะ private PyPI ที่มีการป้องกัน https://news.ycombinator.com/item?id=44712558
ผมไม่ค่อยเข้าใจประเด็นของคำพูดนี้ จริง ๆ แล้ว Charlie Marsh ได้อธิบายเรื่องนี้ไว้ตรง ๆ ตั้งแต่เดือนกันยายนปีที่แล้ว ว่าตัวอย่างเชิงกลยุทธ์อาจเป็น private package registry สำหรับองค์กร (ไม่จำเป็นว่าต้องทำแบบนั้นจริง แต่ยกมาเพื่อให้เห็นภาพกลยุทธ์ให้ชัดขึ้น) Astral โปร่งใสมากเรื่องโมเดลธุรกิจ https://hachyderm.io/@charliermarsh/113103605702842937
คำว่า “หารายได้” อาจฟังดูเป็นลบ แต่พวกเขาสร้างเครื่องมือที่ยอดเยี่ยมมากจริง ๆ ดังนั้นในมุมบริษัทที่อยากให้ช่วยแก้ปัญหาได้มากขึ้น ก็ย่อมยินดีจ่ายเงิน
ผมยังไม่ได้นำ uv มาใช้ และกำลังรอดูว่าในอนาคตจะเดินไปทางไหน ช่วงหลังมานี้แม้แต่การใช้เครื่องมือของ Anaconda เองก็ต้องกลับมาทบทวนเพราะการเปลี่ยนแปลงไลเซนส์ เช่นเดียวกับ Qt แค่คิดว่าจะต้องเจอปัญหาเรื่องไลเซนส์อีกก็รู้สึกหนักใจแล้ว