Live data from Hacker News

Mongrel2 Says, "Goodbye Python"

sheddingbikes.com

201–210 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#201

Earlier quoted context omitted.

This is very interesting and is what RVM in the Ruby world was designed to solve in some way. So maybe we need a widespread and useful PVM. This feeds into an observation of mine I made over five years ago but that seems to be ever more relevant as time goes by. Linux and BSD seem to have "solved" the packaging problem through mega-repositories with dependencies and access to source code. However your favorite langua…

have there own repositories that are _not_ linked into the systems way of doing things One approach is to have a system that packages everything in the language-specific repository for the distro. Haskell on Archlinux is an example of this. I'm not a fan of actually using the language-specific packages because I like the rolling release model and end up having to do some manual work to reinstall all my packages when…

I've no direct experience of Arch, but the traditional problem with integrating rubygems is that it expects to be able to install more than one version side-by-side. That's alien enough from the packge management point of view, but when it's de facto idiomatic to specify required versions and manipulate the load path at runtime, it makes integrating with a distro downright fiddly.

Re: Mongrel2 Says, "Goodbye Python"

#202
post #104

Earlier quoted context omitted.

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-e…

If you build yourself a new python, what's the point of virtualenv ? Compiling python is of course possible, although quite a chore if all you want is to configure some software. Concerning the need to obtain a new python if you want to use a newer python: yes, it is more or less evident, but that's Zed Shaw's point, not mine. Where he has a point IMO is about the brokenness of the installed python - many distributio…

The point is that building a new Python just to generate virtualenvs from is not disruptive to anything else. Zed says they had to move away from Python because the system would get messed up if you replaced the distro-supplied Python. Building a new Python and merely using it from the build directory to generate virtualenvs doesn't disrupt anything in the system. We have done this on several CentOS systems and had no issue.

You just build it and don't install it, run it from the build directory or some other isolated space that won't effect the system. You _can_ create venvs from there. After you have done so, just carry your venv around with you and there's no disruption from anything. Our venvs are all kept in project-top-level/venv.

Re: Mongrel2 Says, "Goodbye Python"

#203
post #20

Earlier quoted context omitted.

Stuff that belongs to the OS (but runnable by all users) is in /usr/bin. That's FHS. Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs Seriously. Use virtualenv (and virtualenvwrapper). http://www.doughellmann.com/projects/virtualenvwrapper/

People who don't do Python won't/can't use virtualenv. Also, you don't think that's a nasty workaround for something that should just be a non-issue? That's like you telling me to use NetBSD pkgsrc just to get around some ancient linux (which I have done).

Hi Zed. For the specific case of needing Python 2.6 on RHEL, ask your user to install the 'python26' package from EPEL. It's a semi official source of packages for RHEL including newer versions of OS tools that slot alongside those versions.

Re: Mongrel2 Says, "Goodbye Python"

#204
post #199
post #47

Earlier quoted context omitted.

> What about stuff that belongs to me (the sysadmin) but runnable by all users? If you're writing quick ad-hoc scripts and don't have time to package, /usr/local/bin. Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it. We can't and probably don't want to change that, so we'll need to live with it. Use virtualenv. if you need to to, install a quick Python 2.…

Not to nitpick here, but I want to clarify something you said. > Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it. The OS doesn't need python. It is some package you have installed that needs python, like Gnome(py-gtk2) or KDE(py-qt), for your desktop environment or some application you decided you needed. If you don't understand what program on your serv…

> The OS doesn't need python. It is some package you have installed that needs python

No. The installer and packaging system need Python. Anaconda and Yum depend on it. Try removing it and see. You cannot install a minimal RHEL or Fedora system without Python. I am fairly sure this applies to other distros too.

Re: Mongrel2 Says, "Goodbye Python"

#205
post #170

Earlier quoted context omitted.

Let's try to be constructive here! Come up with solutions and ways to avoid the problems mentioned in the future. There's always fashions and trends sure, but I think most people chose to program their last web app in Python or Ruby over assembly for more practical reasons...

heh true, although you sure can learn a lot doing things the 'unaccepted' way. So I'd actually advise everyone to try writing a webapp in assembly. If most people tell you what you're doing is crazy, it's often a big sign that you should do it.

"They laughed at Columbus, they laughed at Fulton, they laughed at the Wright brothers. But they also laughed at Bozo the Clown."

Re: Mongrel2 Says, "Goodbye Python"

#206
post #63

Earlier quoted context omitted.

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…

"Big"? You keep using that word. I do not think it means what you think it means: $ rm src/parser.c src/cli.c src/lexer.c src/linenoise.c $ wc -l src/*.c src/*.rl 148 src/ast.c 646 src/commands.c 267 src/config_file.c 93 src/constants.c 36 src/m2sh.c 13 src/token.c 186 src/cli.rl 156 src/lexer.rl 1545 total That's dinky tiny, even with the linenoise and generated files it's only 4061 lines long, which isn't much at a…

My count is 4636 lines, and I can imagine much. much smaller Python 2.3 code:

    ast.c 115
    ast.h 45
    cli.c 482
    cli.h 31
    cli.rl 143
    commands.c 498
    commands.h 5
    config_file.c 193
    config_file.h 27
    constants.c 82
    constants.h 14
    lexer.c 360
    lexer.rl 121
    linenoise.c 433
    linenoise.h 40
    m2sh.c 27
    mimetypes.csql 851
    parser.c 1074
    parser.h 15
    parser.y 69
    token.c 11

Re: Mongrel2 Says, "Goodbye Python"

#207
post #199
post #47

Earlier quoted context omitted.

> What about stuff that belongs to me (the sysadmin) but runnable by all users? If you're writing quick ad-hoc scripts and don't have time to package, /usr/local/bin. Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it. We can't and probably don't want to change that, so we'll need to live with it. Use virtualenv. if you need to to, install a quick Python 2.…

Not to nitpick here, but I want to clarify something you said. > Per above, Python is used by your OS. It's installed by default, and not uninstallable, because the OS needs it. The OS doesn't need python. It is some package you have installed that needs python, like Gnome(py-gtk2) or KDE(py-qt), for your desktop environment or some application you decided you needed. If you don't understand what program on your serv…

Not true. In some Linux distros Python is used for system scripts, instead of sh.

If you don't understand what program on your server required python to be installed, then you shouldn't be administering a server

Quite.

Re: Mongrel2 Says, "Goodbye Python"

#208
post #14
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…

python26 on RHEL 5 is a 20 second install from EPEL. It leaves python intact. Zed and his audience didn't know this.

Re: Mongrel2 Says, "Goodbye Python"

#209
post #203

Earlier quoted context omitted.

People who don't do Python won't/can't use virtualenv. Also, you don't think that's a nasty workaround for something that should just be a non-issue? That's like you telling me to use NetBSD pkgsrc just to get around some ancient linux (which I have done).

Hi Zed. For the specific case of needing Python 2.6 on RHEL, ask your user to install the 'python26' package from EPEL. It's a semi official source of packages for RHEL including newer versions of OS tools that slot alongside those versions.

Or, just rewrite in C and everyone except Python people will quit bitching. :-)

Re: Mongrel2 Says, "Goodbye Python"

#210
post #206

Earlier quoted context omitted.

"Big"? You keep using that word. I do not think it means what you think it means: $ rm src/parser.c src/cli.c src/lexer.c src/linenoise.c $ wc -l src/*.c src/*.rl 148 src/ast.c 646 src/commands.c 267 src/config_file.c 93 src/constants.c 36 src/m2sh.c 13 src/token.c 186 src/cli.rl 156 src/lexer.rl 1545 total That's dinky tiny, even with the linenoise and generated files it's only 4061 lines long, which isn't much at a…

My count is 4636 lines, and I can imagine much. much smaller Python 2.3 code: ast.c 115 ast.h 45 cli.c 482 cli.h 31 cli.rl 143 commands.c 498 commands.h 5 config_file.c 193 config_file.h 27 constants.c 82 constants.h 14 lexer.c 360 lexer.rl 121 linenoise.c 433 linenoise.h 40 m2sh.c 27 mimetypes.csql 851 parser.c 1074 parser.h 15 parser.y 69 token.c 11

No, most of that is generated from the .rl files or just SQL that's common to everything. Also, you'll want to throw in all of Storm and PyREPL if you want a real comparison.

Then again, 4600 lines of anything is tiny. You have a massively skewed view of "Big" and haven't disproven anything by finding 600 lines of cruft in one directory.

Post reply on HN