TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Many Layers of Packaging: Why PyPI Isn't an App Store

144 点作者 mhashemi大约 8 年前

6 条评论

Mister_Snuggles大约 8 年前
&gt; PyPI, pip, wheels, and the underlying setuptools machinations are all designed for libraries. Code for developer reuse.<p>Many Python applications seem to disagree with this point. The one I most recently deployed, Mayan EDMS[0], includes installing the application using pip.<p>On a side note, one thing that&#x27;s always driven me nuts about having multiple package managers is that they don&#x27;t talk to each other. If I install a system-wide Python library using pip, the system package manager isn&#x27;t aware of it and will try to install the vendor-provided, and usually older, version to satisfy a dependency.<p>Likewise, there&#x27;s no way for pip to ask the underlying OS to install some dependencies - just look at the packages you have to install to get Mayan EDMS running. This isn&#x27;t as simple as asking for a given package name, you have to ask for the name that the underlying OS&#x2F;package manager knows that package by. For example, &quot;apt-get install postgresql&quot; might suffice for Debian, but on FreeBSD you might need something like &quot;cd &#x2F;usr&#x2F;ports&#x2F;database&#x2F;postgresql96; make; make install&quot;.<p>I&#x27;m not singling out Mayan EDMS here, it just happens to be the most recent bigish Python application I&#x27;ve installed so most of what I went through is fresh in my mind.<p>[0] <a href="https:&#x2F;&#x2F;mayan.readthedocs.io&#x2F;en&#x2F;latest&#x2F;topics&#x2F;deploying.html#os-bare-metal-method" rel="nofollow">https:&#x2F;&#x2F;mayan.readthedocs.io&#x2F;en&#x2F;latest&#x2F;topics&#x2F;deploying.html...</a>
评论 #14311622 未加载
评论 #14312050 未加载
andybak大约 8 年前
I love the fact they discuss hardware as a deployment strategy.<p>I considered the same thing at one point where I needed to suggest a bullet-proof way to run some Python code internally at a range of customer sites. A Raspberry Pi plugged into their network isn&#x27;t a bad fix. The amount of time saved by pushing all configuration issues on to the internal IT department outweighs the hardware cost by a few significant digits.<p>I&#x27;m not sure the sheer cheapness of hardware has really sunk in yet. A lot of problems might be better solved by snail-mailing small computers to people.
评论 #14311656 未加载
评论 #14311929 未加载
kalefranz大约 8 年前
Hey HN. Current conda lead developer here. Just want to highlight that transactional rollback for all disk mutating operations (create, install, update, delete) was a big feature in our latest release series. We&#x27;ve closed over 1,000 open issues in the last several weeks, in large part because of the problems that transactions solved.
评论 #14312628 未加载
jefurii大约 8 年前
&quot;The mark of an experienced engineers is to work backwards from deployment, planning and designing for the reality of production environments.&quot;<p>Important point!
评论 #14311667 未加载
评论 #14311041 未加载
评论 #14311039 未加载
nunez大约 8 年前
lovely article.<p>i don&#x27;t agree with pip not being an app store. the best way to deploy something is to deploy onto the most convenient medium for your target audience. so if i need a cli tool or app that happens to have an API, pip or homebrew&#x2F;chocolatey&#x2F;yum&#x2F;apt&#x2F;etc are the best delivery mechanisms for it. however, i wouldn&#x27;t tell our execs to pip install some app they need; i would self-contain everything, ship it with a pretty installer and host it on s3.<p>that being said, rpm&#x27;s or deb&#x27;s are a great way of packaging anything to *nix servers and have been for ages. yum and apt are pretty much guaranteed to be available and the rpm build file format is pretty powerful (albeit unfriendly to look at). we&#x27;ve deployed app artifacts via rpm with good success
kensai大约 8 年前
Just in case you tl;dr<p>&quot;A summary of our lessons along the way:<p>1. Language does not define packaging, environment does. Python is general-purpose, PyPI is not.<p>2. Application packaging must not be confused with library packaging. Python is for both, but pip is for libraries.<p>3. Self-contained artifacts are the key to repeatable deploys. Containment is a spectrum, from executable to installer to userspace image to virtual machine image to hardware.<p>4. &quot;Containers&quot; are not just one thing, let alone the only option.&quot;
评论 #14310715 未加载