On Wed, Sep 22, 2010 at 12:59 AM, Diez B. Roggisch <de...@web.de> wrote: > David Cournapeau <courn...@gmail.com> writes: > >> On Tue, Sep 21, 2010 at 10:23 PM, Diez B. Roggisch <de...@web.de> wrote: >>> Ant <ant...@gmail.com> writes: >>> >>>> Hi all, >>>> >>>> I've just seen this: http://sheddingbikes.com/posts/1285063820.html >>>> >>>> Whatever you think of Zed Shaw (author of the Mongrel Ruby server and >>>> relatively recent Python convert), he has a very good point in this. I >>>> run Fedora 12 on my home computers, and find it far too much hassle to >>>> try to get Python 3 installed. Even the 2.x's are behind - IIRC think >>>> it currently uses 2.5. >>>> >>>> So I really think this is a barrier to entry to Python 3 that we could >>>> do without - it's the only reason I do all of my Python work in 2.x, I >>>> would jump at migrating to Python 3 if it was easily available on >>>> Fedora. >>>> >>>> Is there a solution to this that anyone knows of? Has Zed jumped to >>>> conclusions? Have I? >>> >>> I think he has a very valid point. I've been arguing quite a few times >>> here that e.g. the stupid splitting up of python and python-dev packages >>> that a great deal of people trip over should go away. >> >> It is not stupid, it makes a lot of sense when you know the >> distributions in question. It means you have a consistent behavior >> independently of the language. So of course if you don't care about >> the rest of the ecosystem, you will think it is useless overhead. > > The point is that the distro doesn't care about the python eco > system. Which is what I care about, and a lot of people who want to ship > software. > > Don't get me wrong: I'm a Linux user for way over a decade, I enjoy the > package management in providing a consistent distribution. > > What I'm talking about here are 3rd-party > developers/companies/whatever, and people who want to install software > that requires recent versions of packages *not* provided by their > distros. I should have made that point clearer I guess. > >> >> Also, I doubt that the issue is python vs python-dev - of course, >> given that the exact issues are not explained, we can only play guess >> games. > > The problems explained are simply outdated and crippled python > versions. > > And to me, a python version installed that has not the > distutils module is *crippled*. You can rationalize that as much as you > want through some package philosophy saying "we don't ship development > related files", but to me a simple installation instruction that says > > "run 'python setup.py install'" > > which fails because of such a (debatable) decision sucks. Yes, there are > corner-cases when you need GCC to compile an extension. But that's still > catering to the 80% or even more (I'm guessing here) of pure-python packages. > > Of course, in a ideal world, distutils would hook into the distros > dependency system + simply say "please install python-dev first". > > But I'm not convinced that putting the weight here on the shoulders of > the python-communtiy to deal with arbirtray decisions of the dozen or > how many distros + packaging schemes out there is possible - and helpful. > >>> But usually people here seem to think that other package management >>> systems are the way to go, and python itself must integrate with >>> them. E.g. providing dependency information compatible to them and their >>> policies. >>> >>> I think that's bonkers. You can't support every new kid on the block >>> claiming to be the shizzle in package management. Or the next distro >>> with it's own packaging policies. And of course the overall release >>> planning that says "we use that ancient stable version not supported for >>> years anymore, because it's true & tested for us". >>> >>> IMHO the solution to this is the way Apple does it: they have a System >>> Python. Don't mess with it. Seriously. Don't. >> >> Apple's python have caused more issues than all distributions >> altogether for Numpy and scipy, at least as far as python itself is >> concerned. It is very confusing for many end-users. > > Exactly. My point is that I can safely install a second version besides > it, and don't use the system's python that is there and kept stable for > the system's own belongings. > >>> So, in summary, I think if anything, Python should liberate itself from >>> the reigns of distro package management, and fix whatever issues there >>> are with setuptools (or distutils or pip or distribute or whatever the >>> cool kids use these days). And then make people use that to work with >>> Python-packages, potentially even in individual, isolated VirtualEnvs >>> because of package version conflicts. >> >> This kind of thinking mostly shows a poor understanding of complex >> deployment scenario. If everybody worked like that, you would quickly >> be unable to build anything stable. True, conflicts are sometimes >> unavoidable, but if every library keeps changing your only solution is >> isolated environments, you quickly have a mess of a system where many >> combinations of libraries are not possible. > > And now you are already in a mess of a system where many combinations of > libraries are not possible. And the thinking of "one version set to rule > them all" shows a poor understanding of the need for legacy code's > specific version requirements, as well as the need for fluctuating, > (sometimes cutting edge) libraries. > > Does that suck? Sure. But the answer can't be a system that ties you in > with *outdated* software for *years*. And it can't be Python's or it's > communities burden to provide the solutions for the mass of distro providers. > > I *am* in the situation to need to deploy > a TurboGears2 application every day on a debian lenny machine. Guess > what that means: > > r...@web01 / 15:55:43 # aptitude install python-turbogears -Vs > Reading package lists... Done > Building dependency tree > Reading state information... Done > Reading extended state information > Initializing package states... Done > Reading task descriptions... Done > The following NEW packages will be installed: > python-cheetah{a} [2.0.1-2] python-cherrypy{a} [2.3.0-1] > python-configobj{a} [4.5.2-1] python-crypto{a} [2.0.1+dfsg1-2.3+lenny0] > python-decoratortools{a} [1.7-1] > python-dispatch{a} [0.5a.svn20080510-1] python-dns{a} [2.3.3-2] > python-elementtree{a} [1.2.6-12] python-elixir{a} [0.6.0-1] python-flup{a} > [1.0-1] python-formencode{a} [1.0.1-1] > python-kid{a} [0.9.6-1] python-mysqldb{a} [1.2.2-7] python-nose{a} > [0.10.3-1] python-openid{a} [2.2.1-2] python-openssl{a} [0.7-2] > python-paste{a} [1.7.1-1] python-pastedeploy{a} [1.3.2-1] > python-pastescript{a} [1.6.3-1] python-pkg-resources{a} [0.6c8-4] > python-protocols{a} [1.0a.svn20070625-2] python-pysqlite2{a} [2.4.1-1] > python-scgi{a} [1.12-0.2] > python-setuptools{a} [0.6c8-4] python-simplejson{a} [1.9.2-1] > python-sqlalchemy{a} [0.4.7p1-2] python-sqlobject{a} [0.10.2-3] > python-turbogears [1.0.4.4-1] python-turbojson{a} [1.1.2-1] > python-turbokid{a} [1.0.4-2] python-webpy{a} [0.230-1] > 0 packages upgraded, 31 newly installed, 0 to remove and 0 not upgraded. > Need to get 4936kB/5188kB of archives. After unpacking 29.3MB will be used. > > Turbogears 1.0.4? Thank you - can't use that. > >> The fact is that if you need to assemble softwares from many sources, >> you need proper engineering. Isolated environments do not help you >> much with that. Maybe you should consider that distros have an >> experience that you don't, > > I don't deny them their experience. Do you deny the experience of other > people with *other* needs? As I already said: I don't propose to ditch > the package management. I'm all fine with a distro that carefully > selects it's packages and dependencies.
In your previous email, you were "suggesting" that we should make people use a specific set of python-specific tools. That does not sound very consistent with the idea of letting people choose what they want to use. FWIW, I think those tools are already pushed too aggressively, confusing many people who use pip, virtualenv, etc... for dubious reasons ("I read somewhere that I should use this"), and causing numerous bug reports on the numpy/scipy mailing lists. David -- http://mail.python.org/mailman/listinfo/python-list