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

[Daniel Fetchinson]

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