[Python-Dev] Sumo

[Yaniv Aknin]

>
> > Because scientists, financial analysts, web designers, etc all have
> > different needs.
>
> My point is just that a web designer probably doesn't care if he's
> got numpy, nor does a mathematician care if he has cherrypy
> onboard. They only care when the tools they need aren't there,
> which is where sumo can help.


Why do we want "distributions" (whether 'sumo' or domain specific) in the
first place? Obviously because we have some pains to alleviate, but I think
Linux distributions, particularly Ubuntu, have been coping with similar
pains for a while now with good results. I used to be rather informed on the
state of Linux distributions circa the end of the 90's. Should I use this
distribution or that one? Now I don't care, the answer is always 'Ubuntu,
and apt-get it to fit your needs'.

The pain list, as I see it:
(a) Make it easy to find functionality that you'd typically be tempted to
implement alone
(b) Make it trivial, mind boggling easy, to add this functionality to your
interpreter once you know of it
(b.1) Make it easy to package a Python 'distribution' so end users don't
need to muck around with (b)
(c) Make it easy for software to specify its requirements in code and get
them mostly automagically
(d) Make it *legally* least painful to acquire and use endorsed
functionality sets
 ... (pipe in if I missed something important)

I'm wondering if expanding the efforts in Python packaging ("easy_install"
and PEP376 comes to mind, only on steroids) isn't the correct solution for
alleviating these pains in a much better fashion. I'm not saying it's easy,
but I think that superb packaging technologies are a very well proven
technology, that they're well within the community's capabilities/needs and
that maximizing flexibility is a move in a better direction than creating
one or two or seven 'distributions'.

I hope you would intuitively grasp what I mean, even if I fail to articulate
it well, if you ever used dpkg and apt-get (or equivalents), along with the
ability to add sources and the simple distinctions between sources (core vs.
universe vs. multiverse), along with eco systems like launchpad and PPAs,
etc. To my 1999 self these features of Ubuntu seem like miracles, not so
much because Debian and dpkg/apt-get weren't there back then (they were life
saving back then too), but because of the whole system's huge support base
and centrally-designed decentrally-implemented nature. 'apt-cache search' is
usually how I find new software these days, and the same could be true for
Python when I need futures or multiprocessing or whatever. I could write
lots about what I think we should have in such a system, but maybe it's more
befitting for python-ideas or a blog post than here; for this argument,
'mirror Ubuntu's winnage' is a good enough description. I think a good and
lively packaging system beats 'distributions' any day.

This leaves us only with the legal pain, which I felt harshly on my flesh
following some acquisition by a corporation and it's painful and frustrating
and mostly unreasonable. I suspect, though I'm a legal n00b (and proud of
it), that packaging in multiple repositories like Ubuntu does could help a
lot, along with taking some responsibility over the most recommended repo
(candidates are the 'almost made it into stdlib' packages, maybe even the
giants like Django, NumPy, TurboGears, Twisted, etc). This is not about
development responsibility and surely not about taking legal liability, it's
about actively helping facilitate these packages' use in hostile legal
environments. While the hackers in the trenches working on trunk and py3k
may not care much (and probably needn't care much), I humbly think the PSF
may care more and is best equipped to help. Maybe by requiring certain
licenses for 'recommended' repo inclusion, maybe by working with the likes
of Google or IBM on publishing legal reviews of select Python distributions,
I don't know, depends what would help a corporate lawyer make speedy
approval.

 - Yaniv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100527/c2cb244f/attachment-0001.html>