Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

Post reply on HN
Print view View original

61–70 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#61

Post by Sukotto »

rbanffy wrote: post #41

It's funny how, for Zed, anything that doesn't work the way he thinks it's supposed to work is "broken" and the result of some boneheaded decision and that it "sucks". I too am frustrated by ancient versions of server OSs that use equally ancient versions of Python, but that's why virtualenv was invented. And source distributions. I am happy using it when required. Being "stable" in OS terms is not changing APIs very…

I certainly think that anything that doesn't work the way I expect is broken and things that are broken in this way frequently suck... and that seems to be the attitude of most of the people I know.

Re: Mongrel2 Says, "Goodbye Python"

#62

Post by cookiecaper »

cdavid wrote: post #14
nailer wrote: post #7

I understand what Zed's saying here - particularly as I came to programming from a sys admin background. Just like Perl before it, Python (and to some extent, Ruby if you use Puppet) are part of the OS (Linux OS or OS X that is). Shit can and will break if you mess with your OS. You never got this with PHP because people didn't use it in their OSs. But there's a simple solution: not only does the Ministry of Packagin…

I am curious: how do you think virtualenv and pip would solve the issue of antiquated python ? The only thing that virtualenv does is to install packages in some temporary location, that you can throw away later without impacting anything outside python. Virtualenv does nothing to solve those issues. I am actually wondering whether it does not even aggravates them because people think those tools magically solve back…

Create your virtualenv with --no-site-packages. Of course you have to use a different Python to run virtualenv, it's not that hard to build but if you have something against that it shouldn't be too hard to find a newer binary out there somewhere.

So, what's the complaint here? You have to obtain a new version of Python if you want to use a newer version of Python than what comes with the system? That's pretty self-evident imo.

Distro makers hate statically-linked stuff as a general rule and virtualenv is basically a statically-linked Python application. How many distros do you know that send out games statically linked to SDL or whatever? Most would rather have the application break. The same is true for Python; the distro has a philosophical opposition to static linking and virtualenvs are essentially statically-linked Python apps.

Re: Mongrel2 Says, "Goodbye Python"

#63

Post by acqq »

ubernostrum wrote: post #55
acqq wrote: post #40

Earlier quoted context omitted.

Why is it "simply unacceptable" to produce the code to the least common denominator? Anything that is successful must have more versions in the installed base. You can target a single version of something only if it's not used at all. It seems too much developers live in "Everybody must have that what I have" world. I haven't tried myself, but I can't believe Python changed that much that you can't write the plain Py…

You can write code that runs on 2.4, yes. But you miss quite a few useful features of more recent Pythons by doing so (context managers, for example, are a big deal, as are several of the newer standard-library modules). The same thing used to happen with Python 2.3; you could write 2.3-compatible code, but it meant no decorators, no generators, etc. Python has these useful features and has had them for years; why is…

In his particular case, he certainly was not missing the newer Python modules as he was able to write a "small" C-only replacement. That what he wrote in C would certainly be easier to write in Python 2.4 (or 2.2)

Did you understand that he wrote the big C program just to process a small file with the syntax as in the following example (taken from his own file):

    main = Server(
        chroot="./",
        hosts = [mongrel2]
    )
    settings = {"zeromq.threads": 1}
    mimetypes = {".txt": "text/plain"}
    servers = [main]

Re: Mongrel2 Says, "Goodbye Python"

#64

Post by dagw »

nailer wrote: post #52
dagw wrote: post #24

Earlier quoted context omitted.

My point is that /usr/bin/python probably shouldn't be a core OS component. /usr/bin/python should be whatever I want it to be. The core OS-component should be something like /sys/bin/centos-python which I will never directly use, touch or even necessarily know about. The bottom line I guess is that mixing core OS components and user installed software in the same directory structure with no way of differentiating th…

because, as the other poster mentions, /usr/bin has been a place for non-essential (not required by the machine to boot) software for thirty five years .

I know, but that doesn't necessarily make it a good solution. I've been a sys admin for several large unix systems and variations on the problem Zed describes needed to be hacked around on each and every one of them.

Re: Mongrel2 Says, "Goodbye Python"

#65

Post by jacquesm »

gaius wrote: post #18
dagw wrote: post #11

Earlier quoted context omitted.

Shit can and will break if you mess with your OS. Updating a program I use should never constitute "messing" with my OS, it should constitute "using". Why should I as an OS user have to constantly worry about upsetting the OS maker? Why should I have to jump through obscure hoops just to install some software without breaking my OS? Wouldn't a better solution be for the OS makers to wall off their magic python behind…

In the ancient days, stuff the OS relied on was in /usr/sbin and stuff that was "yours" was in /usr/local/bin (or /opt) and stuff that no-one was quite sure whose it was was in /usr/bin. And lo, peace and harmony did reign upon the face of Unix. And the sysadmin did lie down with the developer, and it was good. Who even knows how it works these days?

If there is one thing that ticks me off about modern unix it is that to install I end up having to install / upgrade half the rest of the system because of all the interdependencies between packages.

Re: Mongrel2 Says, "Goodbye Python"

#66

Post by ubernostrum »

acqq wrote: post #63
ubernostrum wrote: post #55

Earlier quoted context omitted.

You can write code that runs on 2.4, yes. But you miss quite a few useful features of more recent Pythons by doing so (context managers, for example, are a big deal, as are several of the newer standard-library modules). The same thing used to happen with Python 2.3; you could write 2.3-compatible code, but it meant no decorators, no generators, etc. Python has these useful features and has had them for years; why is…

In his particular case, he certainly was not missing the newer Python modules as he was able to write a "small" C-only replacement. That what he wrote in C would certainly be easier to write in Python 2.4 (or 2.2) Did you understand that he wrote the big C program just to process a small file with the syntax as in the following example (taken from his own file): main = Server( chroot="./", hosts = [mongrel2] ) settin…

I'm concerned with the general case of writing Python software. Zed's example perhaps could get by, but offers some minor annoyances.

Distributing a framework like Django, on the other hand, when distros lag six years behind current Python, is a royal pain in the ass.

Re: Mongrel2 Says, "Goodbye Python"

#67

Post by lmz »

dagw wrote: post #54
munchhausen wrote: post #36

Earlier quoted context omitted.

> /usr/bin/python should be whatever I want it to be. Why /usr/bin/python? /usr/bin/ has been for ages the "system" area - why would you want to suddenly usurp it for yourself? /usr/local/bin/python will on most Linux systems be executed ahead of /usr/bin/python, because /usr/local/bin/ usually precedes /usr/bin/ on the $PATH. Thus you can have your cake and eat it too. > The bottom line I guess is that mixing core O…

OS package-management (which can be considered "system" I guess) This is where I and the distro makers disagree. When I use synaptic to install the latest version of foobar, that is not in anyway "system" and foobar should not be dumped in the same directory as core system binaries. There should be a directory that contains everything core to the OS (like python 2.4), which was only updated by the OS updater routine…

It seems like you want BSD ports, or some alternate package repository that has /usr/local as the root. The packages from the OS repository are the OS.

Re: Mongrel2 Says, "Goodbye Python"

#68

Post by moe »

joelmichael wrote: post #23
zeemonkee wrote: post #5

Completely agree. The Linux distros (CentOS is the one I work with most, not out of choice) have antiquated Python versions. You can get round it with virtualenv etc., and I do this as a matter of course when installing Python web applications. For a generic "plug and play" package like Mongrel2 however, where sysadmins just want something that runs straight out of apt-get or whatever, it's a pain and is holding thin…

CentOS is about as conservative an option as you can get, though. Unusably so, in my opinion. None of the other popular distros have packages that old.

CentOS is about as conservative an option as you can get

Wait, wasn't that attribute reserved for debian/stable?

Re: Mongrel2 Says, "Goodbye Python"

#69

Post by rbanffy »

Confusion wrote: post #53
rbanffy wrote: post #41

It's funny how, for Zed, anything that doesn't work the way he thinks it's supposed to work is "broken" and the result of some boneheaded decision and that it "sucks". I too am frustrated by ancient versions of server OSs that use equally ancient versions of Python, but that's why virtualenv was invented. And source distributions. I am happy using it when required. Being "stable" in OS terms is not changing APIs very…

He doesn't blame it on 'some boneheaded decision'. As far as I can see, he doesn't blame anyone, he just notes the current state of affairs, in which the situation is indeed pretty much broken. Not just for him, because he is far from the only one that thinks it should work a certain way. that's why virtualenv was invented Yes and shouldn't it also be the OSes that use it to isolate their default Python install?

It's a design decision. They have a default Python install they support, validate and keep working that you shouldn't mess with. I am pretty sure you can't ruin a RHEL just by installing RPMs from RH's repos. If the Python the OS vendor provides is somewhat inadequate to you, it's your job to provide another one or to use another distro. However, if you choose to write your code against the distro's Python (something that's not that hard, really - 2.4 is a modern language) you can rest assured your code will work for as long as the distro is supported. It's not "broken", not a boneheaded decision. It's just the way it is.

If you require 2.7 or 3.x goodness, you can always set-up different environments separate from the OS's Python and just be happy with it.

And, BTW, I never put boneheaded in quotes ;-)

Re: Mongrel2 Says, "Goodbye Python"

#70

Post by jedbrown »

This is a major problem. PETSc uses Python for configuration and we have to be careful not to use any features requiring >2.3. The last release (this spring) required 2.2 because RHEL3 is still supported (in production phase 3, see http://www.redhat.com/security/updates/errata/) until Oct 31, 2010. Python is easy to install, but it's a lot to ask of users when they just want to get your software up and running. Note that RHEL4 sees end of life Feb 29, 2012 and RHEL5 not until Mar 31, 2014. So Python-2.4 support will have to live for a very long time.

I hate this, but don't see a decent alternative. Many of our users are building in batch environments of varying ages and just want to get their science done. Shell/bash is not very portable, it would be painful to write all the configuration in C (and confusing because people would need to both native compilers and cross-compilers).

Post reply on HN