Live data from Hacker News

Python Deployment Anti-Patterns

hynek.me

121–125 of 125 posts

Re: Python Deployment Anti-Patterns

#121
post #120
post #41

Earlier quoted context omitted.

Chef requires Ruby programming. Puppet doesn't, but the core is obviously Ruby, and you extend it using Ruby. You may possibly like my new project: http://ansible.github.com The core is Python but you can write modules in any language.

Thanks for that! We gave up on chef when one of their version updates failed to work with a prior version, both of which were the OS package defaults. Chef silently failed, no error message, nothing in the docs, nothing even in the source code. Had to do a fair bit of searching to find out why. When open source projects like chef have nobody interested in even documenting much less testing backwards incompatibilities…

That said we are at least talking about python, which has had better release QA and backwards compatibility than perl....

I'm curious as to your experience here. I've found that Perl has by far the best backwards compatibility and release QA of the major dynamic languages. What did you encounter?

Re: Python Deployment Anti-Patterns

#122
post #120

Earlier quoted context omitted.

Thanks for that! We gave up on chef when one of their version updates failed to work with a prior version, both of which were the OS package defaults. Chef silently failed, no error message, nothing in the docs, nothing even in the source code. Had to do a fair bit of searching to find out why. When open source projects like chef have nobody interested in even documenting much less testing backwards incompatibilities…

That said we are at least talking about python, which has had better release QA and backwards compatibility than perl.... I'm curious as to your experience here. I've found that Perl has by far the best backwards compatibility and release QA of the major dynamic languages. What did you encounter?

We don't use as much perl as we used to but the last upgrade issue was amavisd-new (a Spamassassin wrapper). Spamassassin has perl version issues every so often as well. NetDNS used to introduce new bugs about every 4th revision but seems to have been stable for the past couple of years. GNUmp3d and many audio libraries have non-perl revision-related, backwards-compatibility issues with some regularity.

Re: Python Deployment Anti-Patterns

#123
post #122

Earlier quoted context omitted.

That said we are at least talking about python, which has had better release QA and backwards compatibility than perl.... I'm curious as to your experience here. I've found that Perl has by far the best backwards compatibility and release QA of the major dynamic languages. What did you encounter?

We don't use as much perl as we used to but the last upgrade issue was amavisd-new (a Spamassassin wrapper). Spamassassin has perl version issues every so often as well. NetDNS used to introduce new bugs about every 4th revision but seems to have been stable for the past couple of years. GNUmp3d and many audio libraries have non-perl revision-related, backwards-compatibility issues with some regularity.

That makes sense. XS components (compiled code which uses the Perl API) don't have binary backwards compatibility between major Perl releases.

Re: Python Deployment Anti-Patterns

#124
post #122

Earlier quoted context omitted.

We don't use as much perl as we used to but the last upgrade issue was amavisd-new (a Spamassassin wrapper). Spamassassin has perl version issues every so often as well. NetDNS used to introduce new bugs about every 4th revision but seems to have been stable for the past couple of years. GNUmp3d and many audio libraries have non-perl revision-related, backwards-compatibility issues with some regularity.

That makes sense. XS components (compiled code which uses the Perl API) don't have binary backwards compatibility between major Perl releases.

The audio library incompatibilities were API changes. Amavisd's issues are not binary either but do seem mostly socket related.

Re: Python Deployment Anti-Patterns

#125
post #109

Earlier quoted context omitted.

You make it sound like if you do one then you can do 100. Not the case.

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 updated that your daemons get restarted? And what do you do if you need a package that isn’t part of your distribution?

Do you have your own linux distro?
Post reply on HN