>>> Why? Why should every package on PyPI need to support all those Python >>> versions? That should be the decision of the package maintainer. If >>> they want to support every version of Python back to 1.0, they can, and >>> if they want to only support version 2.5 that's fine too. >> >> Why shouldn't packages support more than one python version? > > They can. That depends on the developer of the package.
And if the developer decides to support multiple versions currently there is no infrastructural help that would be available to him. On the other hand, there is infrastructural help available to every developer for distributing their apps: it's PyPI itself. You could ask, why do we need PyPI? Let the developers distribute their code in any way they like, python.org doesn't need to support this. The OP is just thinking out loud that it would be great if developers could count on some help for testing various platforms and versions. And I agree, it would indeed be great. >> Looking at it conversely.... >> >> Why should the package developer dictacte which python version the >> package will run on ? > > Because they're the developer. Who else should decide what Python > versions to support? What are you going to do, hold a gun to their head > and force them to support Python 2.1 when they've written it using 2.6 > features? Nobody wants to point a gun to anyone's head. But if a developer says to himself (without anybody holding a gun, remember) that it would be great if there were ways to make sure that his code works on 2.5, 2.6 and 2.7 (and not 2.4 or before for some reason) because he has good reasons to believe that users of all these 3 python versions want to use his code, then it would be really great if this developer had some help from python.org. He already has help for distribution (PyPI), community advise (comp.lang.python), job postings, etc, a good multiplatform/multiversion testing framework would be a nice addition. It wouldn't be mandatory for developers, just as it is not mandatory to upload packages to PyPI, but it would be nice if something like this is available to those developers who want to use it. >>> For all we know, three quarters of the packages on PyPI have never been >>> tested *at all*. >> >> Right. Why not run some tests.... > > Be my guest. > > >>> What's the dire problem you are trying to solve? >> >> Backward and forward compatability of python package resources. > > That's not a problem, that's a feature. > > What's the *problem* that you are trying to solve? What bad thing will > happen if we don't build your proposed system? I fail to understand what is so mysterious about this. The problem is the following: developer X wants to support python versions a, b, c, d on platforms U, V, W. Developer X has no access to platforms V and W and also has no access to python versions b, c and d. Developer X can not run tests on these platforms and python versions although he really wants to. This situation is what is commonly referred to as a problem. >>> What "Super-Computers" do you know of that run Python? >> >> Google. Amazon web services.. > > They're not super computers. They're distributed networks of "regular" > computers. > > >>> Who is paying for this? >> >>>From as little as $30 per month. Funding isn't so much the issue. > > Whether it is $30 a month or $30,000 a month, who do you expect to pay it? > > >>>> With this basic structure, a daily building/testing infrastructure >>>> working across the different versions of python and operating systems, >>>> could easily become a reality. >>> >>> Oh yeah, "easily". >> >> pypi_packagelist = getallpypipackages() >> >> for package in pypi_packagelist: >> testpackageonallplatforms(package) > > > You don't have either getallpypipackages() or > testpackageonallplatforms(), so this is just Py in the Sky (pun intended) > fantasizing. But okay, for the sake of the argument, let's pretend you > have your cluster, and your test suite. You run the test, and get a list > of 18,000 errors (that's an average of three errors per package). Now > what? This testing infrastructure should be available to developers who choose to opt in. Once they run their code and notice that there are errors, they will go back and fix these errors that otherwise would be undetected until a real person runs into them. Or they could clearly state what platform and python versions the code runs on for sure and on what platforms and python versions the code fails. This would be a great advantage to developers. Actually, the OP's suggestion is a really good one, the people behind snakebite.org realized this already some time ago. To me the idea is very clear and obviously would make the life of developers a whole lot easier and consequently the life of users as well. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown -- http://mail.python.org/mailman/listinfo/python-list
