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

191–200 of 251 posts

Re: Mongrel2 Says, "Goodbye Python"

#191

Post by mcantelon »

briancurtin wrote: post #138
mcantelon wrote: post #129

Python needs something like the "Go PHP 5" campaign (which pressured projects/hosting companies to drop support of PHP 4: http://gophp5.org/ ).

What version should be promoted? As much as I like, use, and work on Python 3, a campaign to get distros to use 3.x would leave a lot of projects in the dust, broken and unusable, or resulting in a rushed conversion. On the other side of the coin, a campaign to promote a newer 2.x version is counterproductive to eventually getting everyone on 3.x.

The latest v2 would be the easiest step to take.

Re: Mongrel2 Says, "Goodbye Python"

#193

Post by thaumaturgy »

zedshaw wrote: post #157
mahmud wrote: post #76

Instead of inventing your own syntax, why didn't you use a portable syntax like XML, JSON, YAML, or better yet, libconfig[1]? Please compare the libconfig test file to the mongrel configuration file: http://www.hyperrealm.com/libconfig/test.cfg.txt http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-190003.... The mongrel conf is a subset of libconfig; it doesn't use the more advanced features. Plus libconfig has bi…

I thought about something like that, but wanted to duplicate the existing config file format so that people's configs would keep working (mostly). It actually had some cool advantages, like a nice psuedo variable system letting you setup variables for reuse in different parts of the config file. I haven't really seen that in other config formats, and it is damn handy.

I do that in the readable config file format I wrote for another web backend, and it is hella useful.

Re: Mongrel2 Says, "Goodbye Python"

#194

Post by kfool »

statictype wrote: post #112
jacquesm wrote: post #65

Earlier quoted context omitted.

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.

I think that's more symptomatic of the open source culture around most Unix systems than Unix itself. Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.

No, it's not symptomatic.

The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too.

There's no mechanism for identifying such minimum possible dependencies.

Re: Mongrel2 Says, "Goodbye Python"

#195

Post by ubernostrum »

dschobel wrote: post #123
ubernostrum wrote: post #107

Earlier quoted context omitted.

The solution to distros which are bundling three year old software is not to halt your progress for three years, that should be obvious. Speaking as Django's release manager: Red Hat's continued use and support of ancient 2.x Python versions has been a factor in the schedule we're developing for migration to Python 3.x. We can't simply pull the rug out from under anyone who's using Django on RHEL.

Seeing RHEL/CentOS keep coming up led me to some googling and the first result for "RHEL python" is http://www.python.org/download/linux/ (about as official as it gets) which says The IUS Community Project maintains recent versions of Python for Red Hat Enterprise Linux (RHEL) and CentOS. Installations are parallel installed next to stock versions of python therefore don't disrupt the functionality of critical python…

Not quite, because not everyone will install that stuff, or will be able to get approval from their higher-ups to install it (folks who run RHEL tend to be pretty conservative...).

Re: Mongrel2 Says, "Goodbye Python"

#196

Post by jacobolus »

zedshaw wrote: post #155
dschobel wrote: post #116

Earlier quoted context omitted.

The question isn't whether there is a problem but whether there is a solution. The virtualenv/pip people seem to think so.

Yes, pip/virtualenv works for installing things like Django. It totally fails for something like m2sh which has to live in the system PATH so that you can run it from wherever you have your configs. But you know, I wonder if the various distros could sort of invert this and they start using pip/virtualenv instead of everyone else working around them?

The distros should be shipping two versions of python (if they need), walling their required old version off somewhere but actively and explicitly including a newer one higher up in the $PATH so that people don’t have to mess with the “system”. The problem is the combination of “system”, “third-party tools”, and “users” trying to use the same python with completely different upgrade timelines. If all of these distros included by default a recent-ish version, and their package managers made updating that one a snap, then third-party tools could stop trying to use system python for anything at all, and users could forget that the “system” python existed.

Unfortunately, since the problematic old python versions are on existing old distro versions, it’s not clear that there’s any easy way to fix this problem.

Re: Mongrel2 Says, "Goodbye Python"

#197

Post by jacobolus »

kfool wrote: post #194
statictype wrote: post #112

Earlier quoted context omitted.

I think that's more symptomatic of the open source culture around most Unix systems than Unix itself. Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.

No, it's not symptomatic. The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too. There's no mechanism for identifying such minimum possi…

> There's no mechanism for identifying such minimum possible dependencies.

Is this true? It seems like this would be one of the most obvious essential features of any package management system.

Re: Mongrel2 Says, "Goodbye Python"

#198

Post by dinedal »

kfool wrote: post #194
statictype wrote: post #112

Earlier quoted context omitted.

I think that's more symptomatic of the open source culture around most Unix systems than Unix itself. Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.

No, it's not symptomatic. The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too. There's no mechanism for identifying such minimum possi…

Not sure that's true, most packaging systems allow the maintainer to specify the lowest version their software is compatible with.

Of course, it may be that the maintainer always specifies the latest version,

Re: Mongrel2 Says, "Goodbye Python"

#199

Post by uxp »

nailer wrote: post #47
dagw wrote: post #26

Earlier quoted context omitted.

What about stuff that belongs to me (the sysadmin) but runnable by all users? /usr/local/bin? /opt/bin? /my/homemade/solution/bin? There is a bunch of stuff that doesn't (shouldn't) belong to the OS, but still be runnable by all users without all of them needing a copy in their $HOME directory.

> 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 server required python to be installed, then you shouldn't be administering a server. Having large numbers of language interpreters and compilers on a server can be considered a security risk, since after someone gains access, that provides him or her a large number of options of what kind of code he or she can run. Even having a C compiler is a risk, since code can then be compiled into programs already present on the system. Security should be first in mind when developing an application server.

On the other hand for a development environment, there should be nothing stopping any distribution from installing multiple language interpreter versions. The default `/usr/bin/python` or `/usr/local/bin/python` can be a symlink to python25, python26 or python27, and when the user needs to run a different version, they explicitly call the binary with the version number. This whole virtualenv method just to parse a configuration file of a program not written in python seemed a little excessive.

Re: Mongrel2 Says, "Goodbye Python"

#200

Post by nailer »

kfool wrote: post #194
statictype wrote: post #112

Earlier quoted context omitted.

I think that's more symptomatic of the open source culture around most Unix systems than Unix itself. Being able to share and depend on other people's libraries is great for the developers as long as they're not tied to providing support for when users can't compile or run their software.

No, it's not symptomatic. The problem is that about 80% of packages in distributions could be compiled against older versions of dependencies, but never do. Be default, distributions mark in the packages the dependency of their currently installed libraries, ignoring the fact that the software could have been compiled against an older version of the library too. There's no mechanism for identifying such minimum possi…

> There's no mechanism for identifying such minimum possible dependencies.

Er, yes there is, and there has been for at least the last 12 years, and probably more.

Requires: python >= 2.6.1

Post reply on HN