hynek

15 ms·

121.
Python 3.3.0 beta 1 released(mail.python.org)
143 points by hynek 14y ago|95 comments
122.
by hynek 14y ago
I don’t want to sound like an old smart ass but I’m regularly grateful how the tech community evolved; the article mentions it too, it was _really_ bad. The usenet of the 90’s and early 2000’s was a fierce battle zone and newbie chip pan. N
123.
by hynek 14y ago
Sure! My first patch was a doc patch too and got committed within hours. We’ve got people that work on the docs nearly exclusively – it’s a big deal for Python to have great docs.
124.
by hynek 14y ago
Well, that sounds the same like CPython. And to be fair, 4 months of that 9 months were myself sulking in the corner – one of the reasons why I wrote that article was to give others the hint to do it better. If you embrace the whole process
125.
by hynek 14y ago
It doesn’t work with files from stacks. Yoink has a keyboard shortcut for that, I haven’t found a similar functionality inside of DragonDrop?
126.
by hynek 14y ago
That’s wrong. The package contains only the application, it’s up to you how you start it. That’s where for configuration (e.g. Puppet or Chef) comes into the game.
127.
by hynek 14y ago
It’s not necessarily about dependencies but about having one self-contained file (= deb/rpm) that can be deployed easily. The idea about doing this kindled when we started deploying Django apps – you can see in the second example that it’s
128.
by hynek 14y ago
I think you missed one point here: The package _contains_ the virtualenv, so you even _must_ have multiple copies of the same package for every app that needs it. That’s the whole point of it: have a consistent and reliable way to deploy wh
129.
by hynek 14y ago
Does it also help with deployment of non-code related files (eg. static files in web apps)?
130.
by hynek 14y ago
I believe the reason is that the position of the virtualenv changes (from /home/buildbot/package-version/vrmd/venv to /vrmd/package/venv) and some links didn't match. I'm not 100% sure though, it's some time ago. :)
131.
by hynek 14y ago
You make fair points here however I was arguing against the widespread “git pull” culture. It's clear that some of the points can be mitigated using more sophisticated git+fab magic. Nevertheless, the other points remain true and the combin
132.
by hynek 14y ago
TBH, we currently just convert the debs to rpms when necessary. But RPM-based servers are only legacy here so it doesn’t happen too often. We have no windows and no BSD _yet_. There might come some FreeBSD for ZFS's sake soonish, then I’ll
133.
by hynek 14y ago
We used to use native tooling, the usage of fpm is rather new in fact. It simplified the code big time without compromising on anything.
134.
by hynek 14y ago
My public services don’t have 100 dependencies and that’s on purpose. Relying on magic distribution fairies for all your libraries is a IMHO a false sense of security, YMMV. How do you make sure that whenever one of your dependencies gets u
135.
by hynek 14y ago
> I currently have to deploy Django-Piston directly from a master branch on GitHub due to some terrible decisions made by developers who never gave deployment a second thought. Avoid this. JFTR, there is a pretty good solution for this
136.
by hynek 14y ago
Not every Python application is a big web app. We have systems that run several smaller Python apps. Python is everywhere.
137.
by hynek 14y ago
> First DO use packages that come with the OS. The OP says that you should not have the distro maintainers dictating what you use. I say, use what is widely available. It takes the headache out of a lot of your deployments. If you are
138.
by hynek 14y ago
> I think his point is that pip can't do this, but learning to actually work with your distro's packaging system properly results in a more powerful and easier to redistribute project. Absolutely. And that’s why I package the whole virt
139.
by hynek 14y ago
You can do whatever you want inside of the post-install hooks which are just shell scripts. Including any kind of soft link black magic. :) And you’re right: replacing files of a running application can lead to all kind of weirdness. I’d ev
140.
by hynek 14y ago
Have a look at fpm: https://github.com/jordansissel/fpm More details to come.
141.
by hynek 14y ago
That’s exactly how we do it too. The only difference is that we don’t install the app using Fabric. Instead, puppet installs the deb with the app into the directory. Maybe I should add a “running apps as root” anti-pattern, but this its 201
142.
by hynek 14y ago
> pushing virtualenv and "self-contained" apps as the one solution is a diservice to the community. Wow. :( > There are valid reasons to rely on your OS, assuming you have an homogenous deployment target (same OS, maybe different ve
143.
by hynek 14y ago
Vagrant ist nice for testing but I’m not going to deploy services to VirtualBox (we use kvm for that). Of course there are dependencies outside of the Python ecosystem but their influence proved to be negligible till now. YMMV. supervisor i
144.
by hynek 14y ago
thanks!
145.
by hynek 14y ago
Fabric is an invaluable deployment tool, but you have to know its boundaries for what it was intended. With Fabric you tell what to _do_ and with Puppet/Chef you define what the result should _look_ like. You define how a server should look
146.
by hynek 14y ago
I’m sorry if that felt to you like that. I’ll consider rewording it. update I added some more context. I would never spit on my beloved tmux. :)
147.
by hynek 14y ago
Honestly I didn’t think it would be necessary. :-/ Your example is btw the advanced version. Many people just ssh on the host, fire up screen and start their server inside.
148.
by hynek 14y ago
Yes you should, but if you have them: do it. That’s what the article says. ;) Please don’t push it in a wrong direction. What I actually wrote is: because we’re a LAMP web hoster, we compile MySQL+PHP+Apache ourself. And because we’re a Pyt
149.
by hynek 14y ago
That’s a plus too. An “aptitude dist-upgrade” is really fast.
150.
by hynek 14y ago
But if you _pin_ your packages, how are you updating? You have to monitor it anyway. High profile projects like simplejson, Django or Pyramid and their deps won’t be missed and the really obscure ones will never make it into the repositorie

More ›