Mongrel2 Says, "Goodbye Python"
sheddingbikes.com
sheddingbikes.com
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 Packaging want you to use virtualenv, your OS maker does too.
The faster pip and virtualenv become standard the better.
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 some wall where I cannot see, touch nor use it, and let me install whatever python I want without fear.
* Just use pip and virtualenv. *
Your OS remains intact, and you get better deployment for free!
Replacing a component of your OS (Python 2.x) with another one (python 2.x +1 ) affects:
* The OS installer (Anaconda on RHEL, Ubuntu'sequivalent)
* The packaging system (yum)
* Many GNOME system admin apps.
* The config management tools (puppet sits on ruby)
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 them is simply bad design.
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 OS components and user installed software in the same directory structure with no way of differentiating them is simply bad design.
Linux distro makers agree with you - if you do not customize environment variables, user-installed software goes into /usr/local/ and the OS package-management (which can be considered "system" I guess) puts executables into /usr/{bin,sbin}.
This tends to work well as long as you keep in mind that everything outside of /usr/local/ (or your customized installation path) may at any update change subject to the will of the "system". I think this is a reasonable setup - it gives the OS vendor the ability to update the system, while giving you free reign in your /usr/local/ playground.
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 (which should be different from the update all the software I've installed routine). Then there should be a directory which contains everything I've chosen to install (like python 2.7) which is where everything that I install via whatever is the normal way to install things on that OS ends up. I don't care too much about what these directories are called, but having them be the same, as it is now, is not an ideal solution in my mind.
As far as the update routines are concerned - you can already have those, by self-selecting which packages do you want to update. As a pro-active measure, you can even lock down packages which should never be updated.
This seems to be fine to me - the advanced user has the means to control the update mechanism, and the casual user can just do an all-encompassing "apt-get upgrade" or an equivalent to make sure that she has all the security fixes.
/ would have one dir:
/myos
And all OS components are under there:
/myos/bin/python
People can install anything they want outside /myos, but I'd make it very clear that the OS owns this folder and it should not be modified.
It's a lot of work - I think I ended up trying to write an iproute2 replacement using ctypes and quit. I wonder if anyone else would be interested...
Who even knows how it works these days?
Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs
Seriously. Use virtualenv (and virtualenvwrapper).
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.
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.6 package that slots alongside your OS package rather than removing it - using RHEL 5 as an example, you'd install 'python26' alongside your existing 'python' package.
> 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.
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.
If the Linux distro you choose doesn't meet your needs, why would you continue to use it? If your Fedora install requires it to be one way, but that doesn't fit the need of the server, it would like one should reconsider why they are using that distro.
If you're running 10,000 machines you don't make changes that you haven't regression tested and aren't committed to supporting. Effectively, you'd need to write your own package manager, maintain your own repository and deal with upstream yourself... You'd be Red Hat.
If you don't understand what program on your server required python to be installed, then you shouldn't be administering a server
Quite.
You can blow away your /usr/local and start from a new ports tree and build it all back up without adversely affecting the system.
Everything system related is in /bin, /sbin, /usr/bin, /usr/sbin depending on whether it needs to be accessible when the system has just / mounted or when /usr is mounted as well.
So in single user mode with just / mounted you have access to various different utilities. Mount /usr and you can expand upon that.
Back in the old days when FreeBSD required perl in its base system switching to a newer version didn't break any of the base system tools (or maybe I just never noticed).
There is something nice about a layout that is properly documented and makes sense: http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...
* 'python' remains installed, at version 2.4
* 'python26' is now installed, into separate folders.
So I just did it by hand, more like 50k...
Microsoft does stuff like this all the time, deprecating good .NET libraries for stupid ones just because of God knows what reasons (none of them intelligible to non-political folk).
If it really was a dependency, I think a bug should be filed against the package. :/
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.
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.
Is this true? It seems like this would be one of the most obvious essential features of any package management system.
Of course, it may be that the maintainer always specifies the latest version,
But it takes over with dependencies of newer versions than necessary.
Er, yes there is, and there has been for at least the last 12 years, and probably more.
Requires: python >= 2.6.1
Requires: python
The automatic mechanism in place is to run ldd, identify the list of libraries used by the executables distributed, and mark those libraries as dependencies. Since the package is build on your newer, Debian 5 package, it requires (automatically) the newer libfoo (like python-2.7), while it would have worked just fine with the older libfoo (python-2.5).
>> Yes there is
> What you mention is a manual mechanism
I agree, they should ditch the automatic ldd method. I justy wanted to correct the inaccuracy of saying there wasn't a way to specify min versions.
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 backward compatibility issue (which is the underlying issue here). If something as trivial as virtualenv would solve those issues, people distributing and packaging stuff would have done something similar for ages.
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.
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 distributions make too many changes w.r.t. upstream without understanding the consequences. To distro's defend, the python packaging solutions are so poorly thought out that python itself is not helping the situation.
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.
Also, virtualenv is hard to sell for people who do not know so much about python.
Another thing is that non-python programmers wouldn't even bother to use virtualenv. Really only Python programmers would.
Someone says something is hard to use.
1/3 of the responses agree.
1/3 of the responses disagree, say it's simple.
1/3 of the responses say it's simple, all you have to do is use additional software package Y to manage X and it works great.
This is usually a sign that there is some merit to the original assertion.
In this case maybe we can listen to those who claim the python situation isn't that bad and have provided specific technical solutions for evaluation.
No. Unless those people are morons, but the guys who actually code them know they're tools for python developers, and maybe for sysadmins of python solutions. Pip and virtualenv for software using Python as a config file format? not a good idea.
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?
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.
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 bindings and versions of it in nearly every mainstream language.
If using libconfig is a good idea, it'll win.
P.s. imho, this is the cool thing about the Mongrel2 stuff. The good ideas can always win, because there really just isn't a whole lot to Mongrel2-core, and everything else is decoupled.
I haven't really seen that in other config formats, and it is damn handy.
Can you please elaborate with some details about how "broken" python is on systems, and the situation with python 2.4? According to the article, "recent Ubuntu releases" had broken/deprecated python installations. A quick search reveals that python 2.5 has been shipping as the default "python" meta-package(?)
http://packages.ubuntu.com/search?keywords=python
Can you also please elaborate any "features" that the install was missing - are these specific modules ?(I think python's sqlite3 is missing by default on Ubuntu. I'm not too sure.) I'm not questioning you or anything, I'm just slightly concerned as we had plans to ship a Python application, and when someone experienced enough has a valid complaint, it makes sense to understand the basis behind that.
Just because he downloaded to his computer whatever later version he likes he can't expect from all distros and all users to have exactly the same version across of all the currently running computers, it's more than unrealistic, it's simply impossible and always will be.
This isn't an "oh, a brand-new version just now came out and it's not in the distros yet" problem. Python 2.4 is six years out of date at this point. Python 2.3, which Red Hat will support until 2012, is even older (and for the longest time Red Hat didn't even use a 2.x Python at all -- they sat on 1.5 forever).
That's simply unacceptable, and creates endless headaches for people who want to distribute software written in Python.
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 Python code to the least common denominator of versions >= 2.4. If you have the specific examples why you can't I'd like to know them.
Edit: I've rechecked, he actually mentions 2.2 as the lowest version he saw, still I believe it doesn't change too much.
Python has these useful features and has had them for years; why is it acceptable to say that it will be 5-10 years before we can reliably use anything new?
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]Distributing a framework like Django, on the other hand, when distros lag six years behind current Python, is a royal pain in the ass.
Meanwhile, anyone who depends on Python for much more than a config-file parser knows what a genuine and large issue this is, and that "just write to the lowest common denominator" is not really a reasonable solution.
And I still don't know if he tried adjusting his already existing Python code to simply be backwards compatible -- he never mentions that, neither why that would be a problem in his particular case.
Regarding Django, see the other replies here about side-by-side installations, it's more than reasonable if you have something big which always runs, but not reasonable for a small config script used once.
$ 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
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 11Then 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.
You're right, 600 lines more or less are irrelevant. I just thought you're measuring something else as I saw the total of 1000 instead of 4000. Still it is all tiny for a real C program.
I also think that the C solution is more portable than the dependence on any version of Python. I also cross-compiled the code for 32 MB RAM mipsel platforms and I agree that only C dependencies are better than any script language dependencies (not counting shell, when it's carefully written).
But I actively use both Perl and Python so I'd still really like to know what was lacking in Python 2.2 or 2.3 or 2.4, of course only in case you already knew that you were to have any Python on the target computer. But then if you couldn't expect to have any Python, then the fact that distros still use older versions wasn't of much relevance.
The platforms upgrades have their own dynamic. But you just shouldn't be surprised that somebody who has the server running for years doesn't want to install the latest Python only to process one config script. Not more not less.
It can be mildly annoying sometimes to have to use 5.6 features when I usually develop on 5.12 or newer, but Perl's policy of backwards compatibility makes this a lot easier than it would be in Python.
Git also has some Python code that targets 2.4, making it compatible with such an old version was relatively easy (see http://git.kernel.org/?p=git/git.git;a=commit;h=23b093ee087e... for an example). A lot easier anyway than rewriting and maintaining that code in C.
I'm less in touch with Perl language development in the past decade, but my impression is that the difference between Perl-5.6 and Perl-5.12 is much less than between these versions of Python and recent releases. This is expected when a language evolves rapidly, but it's rather frustrating to wait 10 years before you can depend on the "new" features being available.
http://news.ycombinator.com/item?id=1712404
The DarkPAN matters
"There is currently some FUD going about in some parts of the Perl community about why we should break Perl 5 backwards compatibility. A short blog entry, schmarkpan, is a good example of the trend: loud, noisy, but clueless and devoid of any content."
My impression is that the difference between Perl-5.6
and Perl-5.12 is much less than between these versions
of Python and recent releases.
That and its wide availability and portability make it a much better target than Python for something like glue in a build system for a project that's mostly in C anyway.
But even though it's backwards compatible with old code it's still somewhat of a pain to write code that works on old releases that don't have the modules / core features you want.
Backwards compatibility also comes at a price. Many of the changes that broke old Python code broke it because old warts were being fixed in Python. There's a lot of equivalent old warts in Perl that haven't been fixed, and there's no plan for doing so (other than Perl 6).
There's a lot of equivalent old warts in Perl that haven't been fixed
Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation.
Perl however doesn't break any of the old warts by default, but developers can easily do so by importing modules like Moose and perl5i in their own code. See http://search.cpan.org/perldoc?Moose and http://search.cpan.org/perldoc?perl5i
Perl's model means that you can usually upgrade any code base from say 5.6 to 5.12 without major headaches. But if you try to do the equivalent with Python 1.6 to 3.0 you'll run into trouble.
There are advantages to both models, but with Perl's you rarely see users with big legacy code bases staying behind on some legacy 10 year old release of Perl that may have bugs and security issues. Users usually just upgrade along with their OS without any major pains.
3.0 yes, but 2.6 is simply not true. code written for 2.2 will work in 2.6, bugs notwithstanding.
That's a silly thing to say w/r/t Python 2.x. What makes people’s Python 2.5 code not run on Python 2.2 (or 1.x) is that new features were added in the mean time. New very shiny happy features that make life a lot easier for developers. Almost all python code continues to work from one version to the next, and it’s easy to write code that will work on all the versions from 2.2 to the present (or whatever), as long as you’re willing to avoid all the nifty stuff.
Basically by “backwards compatibility“ you mean “forward compatibility”.
I guess he must have found these must-have Python 2.5 language features that are so important and desirable in C.
And by the way, don't use new GCC features, because some ancient GCC versions will be supported by Red Hat until 2020.
For God's sake, support != enforce
Not fun, mind you, because I really would have rather been doing it in 2.7 or 3.1, but not impossible or even very hard.
If he insisted that users install Python 3.1 only to run his config script and they complained, I don't blame them. If he had users that haven't had Python at all, then I fully understand what he did. But then he can't blame distros and users for not having the latest and greatest Python version, it's just about the existence of Python on the target platform.
Red Hat Enterprise Linux 5.1 ships with Python 2.4.3.
Solaris 10/4 does not ship with python at all. OpenCSW provides Python 2.6.5 but virtualenv doesn't seem to work with it.
If your application is going to depend on Python then you definitely need to evaluate who's using it. If it's like mongrel2 where sysadmins will need to install it on various Linux distros they might not control, then you're screwed. You'll need some kind of installer that hooks up the right kind of python in a safe area.
If it's more like a Desktop application, then just get it to work on the latest of the desktop Linux variants, and then have it bomb out if they don't have the right python. People on Desktop systems are used to having to upgrade to use software.
http://windrealm.com/tutorials/reading-a-lua-configuration-f...
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).
So at the system level we have RPM and Yum and Ports and Portage and Macports and Fink and Homebrew and AptGet and Conary and yada yada yada but at the language level we have (deep breath) Perl and CPAN, Ruby and GEMS, Python and EGGS, and Emacs and ? and Java and Eclipse plugins and on and on.
I would switch IN AN INSTANT to the distro that integrated all this so that I would only need to go to ONE place to upgrade system packages and language packages. Honestly if nobody does it one of these years I might even be forced to do it myself and make mega $ € ¥.
Hope this makes sense to somebody somewhere. :)
have there own repositories that are _not_ linked into the systems way of doing things
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 the distro upgrades it's copy (or switch to the next 6-month release with Ubuntu and similar).
That's the biggest issue, if you test with library version X and run with library version Y, then any sufficiently complicated program will have bugs that would have been found by testing with the same version of the library you run with.
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 things back.
I mean WTF does yum still require ye olde Python 2.4 ?
Reply: because it's Enterprise.
Generally with Python WSGI applications I tend to keep things sandboxed using virtualenv and pip in any case.
Ubuntu and debian are used by plenty of people in production and are probably the better choice for learning how to set up a server if you already use ubuntu.
Apt is also a great package manager.
It could well be that I'm biased--and you should certainly go with what you are comfortable if this is to be a one-man show--but in the pony show that is choosing a server OS, I'd go with Debian every time.
(I'm an Arch guy these days, but hey...)
Pacman and apt are both better imo, and apt-get build-dep is really great when you need to do a source install but can still use normal dependencies.
(I do use aptitude now instead of apt though)
Wait, wasn't that attribute reserved for debian/stable?
Using Rails 3 is best with Ruby 1.9.2, and yet the only popular distros that install that via their package management system are the rolling release ones, Arch Linux and Gentoo (where it is masked). Most people willing to use this brand new software are also willing to compile their own necessary bleeding edge dependencies, and probably have a generally up-to-date distro preference (like Ubuntu).
Even the latest Debian stable, a notoriously conservative distribution, which is a year and a half old and due to be upgraded soon, uses Python 2.6. I'm not sure it's reasonable to support much past that.
And if you have a well tested, rock stable environment you generally don't want to mess with it if you don't have to, or may not easily be able to.
You want to not support older than Lenny. Well, we have machines that are still on Sarge, though slowly being upgraded. Some of the machines haven't been rebooted since around the time Etch came out and that's the main reason they haven't been upgraded yet.
I also recommend using virtualenv and pip, these tools make it much easier to create an easily reproducable Python environment.
RHEL, meanwhile, does not ship 3.1, 2.7 or 2.6. And to be perfectly honest, if you're seriously distributing Python software you have to take RHEL into account -- "Fedora ships something newer" doesn't help.
So it seems like it's possible to get 2.6 on RHEL. I did it, and I hate Python.
The main problem is that I could upgrade a couple of systems to fix the bug but doing that tends to break python (with the infamous _md5 error) spectacularly :)
Catch 22.
Ubuntu 10.4 has Python 2.6 but I wanted Python 2.7 (which is the LAST 2.x version). So here's what I did: I installed all common dependencies (such as OpenSSL with "apt-get build-dep python2.6", since they're all the same for Python 2.7. Then I installed Python 2.7 with "make altinstall" without disrupting the system's base 2.6 install. Then, I got pip and virtualenv installed.
I've never been happier doing Python development. pip never failed to install a single package I needed, and Python 2.7 is fast and gives me a safe path of migration towards Python 3, whenever the whole byte/str issue in the network libraries (or at least WSGI) is 'resolved'.
Despite the whole version madness across Linux distributions, Python is still my preferred language for web development, and even if that means going through a bit of trouble getting it properly installed on a particular system, hopefully that is something I'll only have to do and document once every few years.
I surely hope all distros eventually catch up with Python 2.7 so we can all stop worrying about this. Thanks for taking the time to make some noise about it ;)
No one needs to know it is Lua, (which also happens to be a marketing problem for Lua, heh).
His decision not to use Lua the second time around is perplexing because he is not averse to reusing third-party libraries and he is already using the code from Lua for URL pattern matching (IIRC).
Also possibly he decided to step outside the language wars because it's less hassle to write your own parser than wrangle language partisans.
The idea behind Mongrel2 is that you can write your own configuration system in any language you want, as long as the final result is an SQLite3 database. The one in C that ships with Mongrel2 is "just" a default - if you don't like it, it's not hard to roll your own.
Here's an early peek Josh's Lua config tool, and a sample config file: http://gist.github.com/578726
Make it standard idiom to have every file of code declare its version-dialect at the top?
Default to throwing warning if interpreter and code version-dialect mismatch?
Have the main code interpreter called by all code files simply be a host for routing code to the correct dialect-version interpreter? Perhaps include an optional "slim" download where the host only includes the interpreter for one dialect-version, but make this non-default\opt-in.
We can learn that it's inevitable that your language will come into fashion, be hyped up to be "the language", then will fall out of fashion and be declared 'dead'.
The idea of a '100 year language' is solid as long as developers don't choose languages like they choose what to wear. Unfortunately though, most developers seem to choose based on current fashion rather than anything else.
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...
If most people tell you what you're doing is crazy, it's often a big sign that you should do it.
When the languages ecosystem is flourishing, I am productive. When it's not, I'm shaving yaks that prefer not to be shaved.
No one wants to implement all of java commons-lang in their language of choice because they'd be lynched by the languages users. I no of no other language with a standard library as annoyingly verbose and complicated as java.
1. Less syntax, so that later language features don't cause upgrade problems and can more easily be worked around rather than causing syntax errors. 2. Awesome package management with everything not core in packages that work with the distros so they don't mind using them.
Both of those are damn hard to do though. Less syntax makes the language fairly unusable (Forth), and package management is just a nightmare in general.
If your language assumes this and supports version-dialect from the start it will be more robust and age gracefully in the long run.
edit: basically it would require too much work or a stroke of pure genius to ensure perfect syntax for a new language in public release 1. Language designers should assume as project age approaches infinity the probability of a syntax revision approaches 1.
edit2: also if the interpreter host could interpret all the older versions up to the latest by default, you could write your code in both 2.7 and 3.1 and use 2.5 libraries with it etc. No need to rewrite every single older library for trivial changes.
"The distros have killed Python."
Said out loud, "here we go", and settled down for some classic Zed.
Can't fault him on it, though.
In short: "...have killed Python" is a hyperbole for saying "I was tired to hear people nagging about dependency on Python". Still, it's a very good thing what Shaw did.
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.
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 utilities on the system.
Doesn't that solve the issue and keep you from being hamstrung by those distros?
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 often. One of the good things is that I know that code I wrote for RHEL 4 the day it was launched will run flawlessly on RHEL 4 today. The primary goal of such a Linux distro is that "it has to work". I won't touch the system parts.
that's why virtualenv was invented
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 ;-)
Any system scripts that require 2.4 can then change their shebang to say /usr/bin/python2.4. At the very same time, packages for newer pythons can be made available for ease-of-use for the rest of the world. This breaks nothing.
An end-user of an application doesn't want to fiddle around with library management tools.
It's a shame he felt he had to tear out Python. I understand the pain of relying on distro-supported Python. You basically have to target 2.3 at minimum if you want to distribute an application. If you have windows users, it can be even more painful.
Theoretically, couldn't you have configure check your setup for Python 2.x? Setup your make process to download and install the proper python in a local build environment? I'm just running off random ideas, not sure if it would be feasible.
Too late for Mongrel2 of course, but C isn't so bad either.
Also, this is how things improve. Someone doesn't like the current state of affairs and changes it.
What specific Python dependency did the move to C cure? What are the most common complains regarding libraries and versions? Perhaps listing them can help change whatever is wrong.
This is an interesting point, especially given the amount of code (relatively small) actually needed to parse the subset of Python the config format uses. That said, the subset is fairly "generic scripting language" since there aren't any declarations, only assignments, lists, etc (at least at a cursory overview).
Very rare, but very nice to see!
Productivity is a function of (familiarity, language, libraries, configuration, runtime). Other languages may be great due to (language, library), but configuration can be a show-stopper. Especially since most devs seem to see library/wrapper writing as a chance to pull in all their favourite cruft dependencies.
I have a lot of python programs that use OpenGL, matplotlib, and a lot other libraries. No problem or very little problems on Linux.
On mac 10.6 you have a limited python version and is very difficult to add matplotlib and other libs, with Windows is a similar pain in the ass, unless you buy it from a commercial scientific distro.
If all would be fine, perhaps my network appliance would be shipped with mongrel2 which would be fantastic.
Doing so would have made your software immune to the broken Python installations.
Disclaimer: I love Python, but I hate that anything but the most trivial code won't run across all versions.
Please, define "all versions" and "most trivial code".
I have very little problems with Pythons ranging from the ancient 2.4 to modern 2.7. Of course, I am careful with what I do. I know if I use a dictionary comprehension I will be limited to 2.7+, so I try not to. I am quite sure a lot of the code I write could run under any 2.x Python with little modification. As for 1.x, I will agree that things get more complicated.
Generators is 2.6+, right?
BTW, an ugly approach I used (more or less as a joke) was to check for generator availability and, in case I can't use them, use a list comprehension instead. There is a performance/memory hit but, depending on what you are doing, it's a usable alternative. And a nice place to hang humorous comments.
But I agree that, if your users don't want to install an alien (from the package manager POV) Python in order to run Mongrel, getting rid of python code is the right thing to do.
It's like having a weird dependency, kind of requiring a Fortran 77 compiler in order to run Perl...
http://docs.python.org/release/2.2/ref/yield.html
Generator expressions are 2.4+:
http://docs.python.org/release/2.4/ref/genexpr.html
That said, I don't disagree with removing the Python dependency from the "core" of Mongrel2. As was noted in an earlier comment, people can always write a config file management tool in any language they want (or Mongrel2 bindings in general, for that matter).
So, what is the big deal? I can swear the oldest Python I had to deal with for the last couple years was 2.4.
(yes, it's overkill)
People who have any trouble with a system perl or python or java are shipping their own versions within the package.
Sap Bussiness Object, for example, comes with its own perl 5.004 and Sun JDK 1.4.
It is also possible to provide an up-to-date package for most used OSes. You cannot replace system's default python interpreter, because to much things in distros are depended on it, put it could be /opt/python
btw, it is only Debian-based systems and RHEL who are lagging behind. Fedora is always up to date.
I'm considering this post as just a flame-generator. There is no problem at all.
what he's saying is the very reason virtualenv exists.
There's really no such thing as the Python language, only "Python 2.2", "Python 2.4", "Python 3". If you want to run Python scripts, you need to have three or four different Python runtimes installed, and that's asking a lot of both the distros and of users who need to keep everything straight, and probably even hack the #! at the beginning of scripts so that they work correctly.
Python 3 is by far, the biggest intentional deviation from the "don't break existing scripts" mantra that's been in place for years.
Why was NLTK stuck on Python 2.4 for years? I might use Python to use NLTK, but why do I have to choose an old Python to get it to work... And what if I want to use it w/ software that needs Python 2.6?
Pretty much the only thing you need to do to make your Python code run on 2.x+ is "don't use features released after 2.x".