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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Musings about Debian and Python

108 点作者 plessthanpt05超过 11 年前

17 条评论

fingerprinter超过 11 年前
I didn&#x27;t realize there was a fight going on.<p>It seems like this is where everyone settled and is a good solution:<p>Virtualenv + pip for development<p>system wide (apt, dpkg) python etc for system tools and packages.<p>This makes sense to me. Keep your personal code sandboxed from your system tools.<p>As an aside, I know there are quite a few tools and programs in both Debian and Ubuntu written in Python. I wonder if we&#x27;ll look back in 5-10 years and realize&#x2F;think this was a mistake. Particularly for UI code. I love me some Python, but I cringe every time I have to interact with a Python GUI application.
评论 #6426909 未加载
评论 #6427038 未加载
评论 #6427863 未加载
评论 #6426852 未加载
评论 #6426860 未加载
Steltek超过 11 年前
I have a slight tangent to this topic: Why does every language need their own package manager? I can understand avoiding a specific distro&#x27;s PM but do we need to reinvent the wheel for every single language? Do we need to poorly reinvent Make just so the build syntax matches the source?<p>It seems like a better solution would be to declare a common interface, both to users and to tools, for each language&#x27;s package system. At least that way there&#x27;s some guarantee (or at least a strong hint to the author!) that any given tool would support some nice-to-have extra functionality.<p>A use case for me is that I see a really neat thing Foo written in an unfamiliar language. Install instructions go something like: &quot;Just run &#x27;simple_make foo&#x27; to try it out!&quot; or perhaps &quot;Just run &#x27;curl <a href="http://get-foo-bar.baz/rootme" rel="nofollow">http:&#x2F;&#x2F;get-foo-bar.baz&#x2F;rootme</a> | sh -&#x27;&quot;. Okay, now perhaps it&#x27;s installed. It might even be installed where I want but it probably won&#x27;t be. But what happens if I need to update it? How can I keep all of these pet projects up to date? I have to go and learn easy_install, gem, leiningen, sbt, maven, npm, go, quicklisp, cabal, etc.<p>I mean, I&#x27;m not too lazy to read up on each tool but it adds up quick and not every tool supports an Autoconf-like --prefix or apt-get {update,upgrade}.
评论 #6428866 未加载
pedrocr超过 11 年前
Where I like to draw the line between apt and rubygems&#x2F;pip is between &quot;things that are base system&quot; and &quot;things that are app deployment&quot;. So in a typical rails stack that would be apt installs the system-wide stack (apache, ruby, passenger, rubygems) and then capistrano is used to deploy my webapps with their gems from my dev machine to their app-specific directory in the production server.<p>This way I can have my sysadmin hat on while setting up the server and depend on debian&#x2F;ubuntu to handle security upgrades and generally create a consistent system. Then I can put my devops hat on and use capistrano and bundler to manage the security&#x2F;dependencies of my own code.<p>But I see where this breaks down. If the base stack is moving at a much faster pace than the distributions (e.g., right now the version of passenger in Ubuntu LTS is incredibly old) it&#x27;s attractive to just ignore the system packages and install everything from original sources (e.g., install ruby from source with rbenv). But doing that is just throwing away the integration work the distribution has done. I&#x27;d much rather include some extra repositories to get updated versions that integrate through apt for the few things that I care to upgrade faster than Ubuntu LTS allows me. Right now that&#x27;s puppet, passenger and a few more.
评论 #6427110 未加载
ekr超过 11 年前
I don&#x27;t want to start any argument, but there is a reason why Stallman recommends writing GNU packages in C (so that users don&#x27;t need to acquire and install all kinds of dependencies, and not just them). I certainly think again about installing something when I see that the software is written in Java or Python, mostly because I don&#x27;t like to bloat my system.
评论 #6426884 未加载
评论 #6428019 未加载
评论 #6426806 未加载
don_draper超过 11 年前
&quot;I prefer virtualenv based setups for development&quot;<p>I&#x27;m a <i>casual</i> python user and I find virtualenv to be very helpful.
zipfle超过 11 年前
The design of this blog is so good that I almost didn&#x27;t notice how good it is.
评论 #6427789 未加载
评论 #6427074 未加载
TheSwordsman超过 11 年前
I think I agree with the blog post in its entirety, as a fellow Pythonista &#x2F; Debianite. The Debian packages that are released always seem to be top-notch, stable, and fit for production. (Let&#x27;s forget the OpenSSL incident, shall we?) I don&#x27;t fear that the new version is going to break my currently installed software, and I&#x27;m not worried about dependencies somehow having been missed causing havoc. It just works.<p>(And when it doesn&#x27;t, it&#x27;s because I did something deep within dpkg&#x2F;apt I should not have.)<p>I can&#x27;t say I&#x27;ve always had the same experience with other distributions which is the reason why I moved to Debian in the first place. Truthfully, I can&#x27;t ramble any specific scenarios off from the top of my head.<p>Any time I&#x27;ve had an issue with a Debian software package, the bug threads have always been constructive with proponents for both sides explaining why it should be one way over the other. Eventually, the best decision is made (even if I personally disagree).<p>However, the sacrifice for this stability is the fact packages can become a bit &#x27;stale&#x27; when it comes to new versions. I don&#x27;t mind sacrifices like this. And if you need newer stuff, that&#x27;s why backports exist.<p>If you want the latest and the greatest use pip. But for the love of all things, couple your pip usage with a virtual environment. Hell, even if you aren&#x27;t using pip get in the habit of using a venv.<p>My only bad experience with virtualenvs was a recent Python security update (related to &#x2F;dev&#x2F;random). The system libraries changed, the Python executable in the venv did not, sadness ensued. Even then, once I figured out the issue, it was a quick fix. Just re-init the virtualenv, and it fixed it for me. No need to move code around.<p>In short, if I want a stable system I don&#x27;t need to babysit, I go with Debian. I trust the people maintaining the packages. I use virtualenvs for 90% of my Python development, and use pip inside of those venvs.<p>Hasn&#x27;t failed me, yet. Probably shouldn&#x27;t jinx myself...
hcarvalhoalves超过 11 年前
In my opinion package management is a non-solution. It doesn&#x27;t solve many obvious problems (all your software is tied inside release cycles, tied to shared libraries and you can&#x27;t have multiple versions of the same package installed), plus it operates under assumptions that don&#x27;t even make sense anymore (we&#x27;re not distributing 3rd party software bundled in floppy disks anymore to tie dependencies together).<p>Installing applications as containerized packages (e.g., Gobolinux, OS X .app) should be the norm. Both apt and pip get it wrong because they don&#x27;t solve any of the above problems by themselves (hopefully you can use pip+virtualenv to achieve containerization, and more recently, LXC).
评论 #6427835 未加载
emillon超过 11 年前
The background of this post is a thread on the debian-python mailing list, relative to a new PEP:<p><a href="http://lists.debian.org/debian-python/2013/09/msg00049.html" rel="nofollow">http:&#x2F;&#x2F;lists.debian.org&#x2F;debian-python&#x2F;2013&#x2F;09&#x2F;msg00049.html</a>
st3fan超过 11 年前
Or do what I did: give up on Python packaging and use Go or a JVM based language that produce single artifact deployables.<p>I have been in this Python mess far too long. Now I just make a .war file or tell Go to compile for my target platform. Both result in single files that can be deployed without post-processing, installing&#x2F;compiling dependencies or whatever ... it simplifies things for everyone. Developers, CI, packagers, ops, security folks.
评论 #6426782 未加载
评论 #6426786 未加载
lmm超过 11 年前
Debian set a bad precedent with their tightly-integrated approach to packaging perl. Users and developers (not unreasonably) expected python to work the same way, with pypi&#x2F;apt interoperating just like cpan&#x2F;apt.
zdw超过 11 年前
More background on Python&#x27;s packaging methods and history: <a href="http://aosabook.org/en/packaging.html" rel="nofollow">http:&#x2F;&#x2F;aosabook.org&#x2F;en&#x2F;packaging.html</a><p>I&#x27;d also add that native packages tend to be far more repeatable when you have to deploy and update a lot of systems in any environment.<p>Note that with tools like fpm or other similar quick and dirty package generation tools, in general don&#x27;t have to stick to the upstream system&#x27;s development guidelines, but you get the benefits of using the native package tools.
focusaurus超过 11 年前
My post on this topic, which is in agreement with this post. <a href="http://peterlyons.com/problog/2012/09/managing-per-project-interpreters-and-the-path" rel="nofollow">http:&#x2F;&#x2F;peterlyons.com&#x2F;problog&#x2F;2012&#x2F;09&#x2F;managing-per-project-i...</a>
jamtan超过 11 年前
I like to get the best of both pip and the distro&#x27;s native package manager ...<p><a href="https://github.com/jordansissel/fpm" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jordansissel&#x2F;fpm</a>
auvrw超过 11 年前
well-written (and -typeset) article, although i think there is probably less controversy around this than the tone of the article suggests?<p>anyway, side note: switched from nm-applet to wicd-client and haven&#x27;t looked back.
评论 #6427859 未加载
Siecje超过 11 年前
virtualenv and pip for your own project and use the package to satisfy requirements of installed programs.
jrochkind1超过 11 年前
interesting that debian and perl have come to the same impasse as debian and ruby.