Python Packages : A looming problem? packages might no longer work? (well not on your platform or python version anyway)

[Steven D'Aprano]

On Wed, 22 Apr 2009 19:06:18 -0400, David Lyon wrote:


> = Introduction =
> 
> One of the big challenges for Python going forward is providing a
> testing infrastructure for Python Packages.

Why is it the responsibility of the Python language to provide such a 
testing infrastructure?


> There are now over 6,000 packages listed on PyPi - and this number can
> only get bigger.
> 
> Then, there are the three major operating systems:
> 
>  * Windows
>  * Mac
>  * Linix/Unix

Linux.

> To complicate the problem, there are now many versions of each operating
> system.
> 
> Multiply those two combinations by all of the versions of Python that
> already exist (not to mention the ones coming) and we start to that we
> are heading into complexity. If there are 4 major windows revisions and
> 4 major Linuxes, and two major Mac platforms, we end up with perphaps
> (6,000 x (4 + 4 + 2)) 60,000 delivery possibilities.


But most of those packages will probably work without modification on any 
platform supported by Python. We can take that as a given (subject to 
correction), because the Python language itself has been tested on those 
platforms.


> That number then needs to be multiplied by the number of python
> versions, which possibly include 2.1, 2.2, 2.3, 2.4, 2.5, 2.6 and coming
> up.. the 3 series...

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.


> So that could be (60,000 x 7 (python versions)) 420,000 variations of
> known python packages.

Could be but won't be.

 
> To date... the testing has been done... we have to assume... manually
> with some automation.

Why do we "have to" assume this? For all we know, three quarters of the 
packages on PyPI have never been tested *at all*.


> But we can't expect package maintainers to be forever testing their own
> code on platforms that they simply don't have access to.

We don't.


> A more reasonable and cost effective option is to have this testing done
> on a server farm virtual environment building infrastructure.

You haven't demonstrated that we need to have all this testing done in 
the first place.


> In simple terms, we need to build all the packages that exist for Python
> on a daily basis on all of the environments and report any issues back
> to the registered maintainers.

We "need" to do this? Why? What's the dire problem you are trying to 
solve? That somebody downloads a random package off PyPI and it doesn't 
work? Oh dear, how will we cope!


> This job is too big to be done manually. We need to use either a
> Super-Computer 

What "Super-Computers" do you know of that run Python?


> or a Server Farm. Fortunately, Server Farms are close at
> hand.
>
> = Server Farm Virtual Environments =
> 
> Google and Amazon web services are two organisations amongst others that
> offer commercial virtual server farms that could be employed to do the
> above build process of all the python packages.

Who is paying for this?


 
> Python scripts would be developed utilising the python "test" frameworks
> to supervise the build on each and every platform.

Who do you suggest should develop these scripts?


> 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".




-- 
Steven.