Re: [Python-Dev] Sumo
One worry with an official sumo distribution is that it could become an excuse for *not* putting something in the stdlib. Otherwise it's an interesting idea. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On 27 May 2010 00:11, geremy condra debat...@gmail.com wrote: I'm not clear, you seem to be arguing that there's a market for many augmented python distributions but not one. Why not just have one that includes the best from each domain? Because that's bloat. You later argue that a web designer wouldn't care if his distribution included numpy. OK, maybe, but if my needs are simply futures, cx_Oracle and pywin32, I *would* object to downloading many megabytes of other stuff just to get those three. It's a matter of degree. I'm genuinely struggling to see how a Sumo distribution ever comes into being under your proposal. There's no evidence that anyone wants it (otherwise it would have been created by now!!) Everything worth making has already been made? Not what I'm saying. But if/when it happens, something will trigger it. I see no sign of such a trigger. That's all I'm saying. and until it exists, it's not a plausible place to put modules that don't make it into the stdlib. Of course its implausible to put something somewhere that doesn't exist... until it does. Hence my point - people are saying futures don't belong in the stdlib but they could go in a sumo distribution. The second half of that statement is (currently) content free if not self-contradictory. I'd say rather that there are a large number of specialized tools which aren't individually popular enough to be included in Python, but which when taken together greatly increase its utility, and that sumo offers a way to provide that additional utility to python's users without forcing python core devs to shoulder the maintenance burden. I don't believe that there's evidence that aggregation (except in the context of specialist areas) does provide additional utility. (In the context of the discussion that sparked this debate, that contrasts with inclusion in the stdlib, which *does* offer additional utility - batteries included, guaranteed and tested cross-platform functioning, a statement of best practice, etc etc). Paul. PS One thing I haven't seen made clear - in my view, they hypothetical sumo is a single aggregated distribution of Python modules/packages/extensions. It would NOT include core Python and the stdlib (in contrast to Enthought or ActivePython). I get the impression that other people may be thinking in terms of a full Python distribution, like those 2 cases. We probably ought to be clear which we're talking about. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
OK, I had an idea here: How about that the people affected by difficulties in getting software approved got together to put together not a sumo-python, but a python-extras package? That package could include all the popular stuff, like SciPy, Numpy, twisted, distribute, buildout, virtualenv, pip, pytz, PIL, openid, docutils, simplejson, nose, genshi, and tons of others. That would be a big download. But here's the trick: You don't *have* to install them! Just bundle all of it. If licensing is a problem I guess you'd need to have permission to relicense them all to the Python license, which would be problematic. But otherwise having a team of people overseeing and bundling all this might not be that much work, and you'd avoid the bloat by not installing all of it. :-) Or would this not fool the company trolls? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
Paul Moore writes: On 27 May 2010 00:11, geremy condra debat...@gmail.com wrote: I'm not clear, you seem to be arguing that there's a market for many augmented python distributions but not one. Why not just have one that includes the best from each domain? Because that's bloat. You later argue that a web designer wouldn't care if his distribution included numpy. OK, maybe, but if my needs are simply futures, cx_Oracle and pywin32, I *would* object to downloading many megabytes of other stuff just to get those three. It's a matter of degree. So don't do that. Go to PyPI and get just what you need. The point of the sumo is that there are people and organizations with more bandwidth/diskspace than brains (or to be more accurate, they have enough bandwidth that optimizing bandwidth is a poor use of their brains). XEmacs has used a separate distribution for packages for over a decade, and it's been a very popular feature. Since originally all packages were part of Emacs (and still are in GNU Emacs), the package distribution is a single source hierarchy (like the Python stdlib). So there are three ways of acquiring packages: check out the sources and build and install them, download individual pre-built packages, and download the sumo of all pre-built packages. The sumos are very popular. The reason is simple. A distribution of all Emacs packages ever made would still probably be under 1GB. This just isn't a lot of bandwidth or disk space when people are schlepping around DVD images, even BD images. A Python sumo would probably be much bigger (multiple GB) than XEmacs's (about 120MB, IIRC), but it would still be a negligible amount of resources *for some people/organizations*. And I have to support the organizational constraints argument here. Several people have told me that (strangely enough, given its rather random nature, both in what is provided and the quality) getting the sumo certified by their organization was less trouble than getting XEmacs itself certified, and neither was all that much more effort than getting a single package certified. Maintaining a sumo would be a significant effort. The XEmacs rule is that we allow someone to add a package to the distro if they promise to maintain it for a couple years, or if we think it matters enough that we'll accept the burden. We're permissive enough that there are at least 4 different MUAs in the distribution, several IRC clients, two TeX modes, etc, etc. Still, just maintaining contact with external maintainers (who do go AWOL regularly), and dealing with issues where somebody wants to upgrade (eg) vcard which is provided by gnus but doesn't want to deal with gnus, etc takes time, thought, and sometimes improvement in the distribution infrastructure. It's not clear to me that Python users would benefit that much over and above the current stdlib, which provides a huge amount of functionality, of somewhat uneven but generally high quality. But I certainly think significant additional benefit would be gained, the question is is it worth the effort? It's worth discussing. I don't believe that there's evidence that aggregation (except in the context of specialist areas) does provide additional utility. We'll just have to agree to disagree, then. Plenty of evidence has been provided; it just doesn't happen to apply to you. Fine, but I wish you'd make the to me part explicit, because I know that it does apply to others, many of them, from their personal testimony, both related to XEmacs and to Python. PS One thing I haven't seen made clear - in my view, they hypothetical sumo is a single aggregated distribution of Python modules/packages/extensions. It would NOT include core Python and the stdlib (in contrast to Enthought or ActivePython). I get the impression that other people may be thinking in terms of a full Python distribution, like those 2 cases. We probably ought to be clear which we're talking about. On the XEmacs model, it would not include core Python, but it would include much of the stdlib. The reason is that the stdlib makes commitments to compatibility that the sumo would not need to. So the sumo might include (a) recent, relatively experimental versions of stdlib packages (yes, this kind of duplication is a pain, but (some) users do want it) and (b) packages which are formally separate but duplicate functionality in the stdlib (eg, ipaddr and netaddr) -- in some cases the sumo distro would want to make adjustments so they can co-exist. I wouldn't recommend building a production system on top of a sumo in any case. But (given resources to maintain multiple Python development installations) it is a good environment for experimentation, because not only batteries but screwdrivers and duct tape are supplied. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:
Re: [Python-Dev] Sumo
Lennart Regebro writes: One worry with an official sumo distribution is that it could become an excuse for *not* putting something in the stdlib. Otherwise it's an interesting idea. On the contrary, that is the meat of why it's an interesting idea. I really don't think the proponents of ipaddr and futures (to take two recent PEPs) would have been willing to stop with a hypothetical sumo. Both of those packages were designed with general use in mind. Substantial effort was put into making them TOOWTDI-able. Partly that's pride (my stuff is good enough for the stdlib), and partly there's a genuine need for it to be there (for your customers or just to pay back the community). Of course there was a lot of criticism of both that they don't really come up to that standard, but even opponents would credit the proponents for good intentions and making the necessary effort, I think. And it's the stdlib that (in a certain sense) puts the OO in TOOWTDI. On the other hand, some ideas deserve widespread exposure, but they need real experience because the appropriate requirements and specs are unclear. It would be premature to put in the effort to make them TOOWTDI. However, to get the momentum to become BCP, and thus an obvious candidate for stdlib inclusion, it's helpful to be *already* available on *typical* installations. PyPI is great, but it's not quite there; it's not as discoverable and accessible as simply putting import stuff based on some snippet you found on the web. And the stdlib itself can't be the means, it's the end. At present, such ideas face the alternative stdlib or die. The sumo would give them a place to be. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On 27/05/2010 16:56, Stephen J. Turnbull wrote: Paul Moore writes: On 27 May 2010 00:11, geremy condradebat...@gmail.com wrote: I'm not clear, you seem to be arguing that there's a market for many augmented python distributions but not one. Why not just have one that includes the best from each domain? Because that's bloat. You later argue that a web designer wouldn't care if his distribution included numpy. OK, maybe, but if my needs are simply futures, cx_Oracle and pywin32, I *would* object to downloading many megabytes of other stuff just to get those three. It's a matter of degree. So don't do that. Go to PyPI and get just what you need. The point of the sumo is that there are people and organizations with more bandwidth/diskspace than brains (or to be more accurate, they have enough bandwidth that optimizing bandwidth is a poor use of their brains). To my mind one of the most important benefits of a sumo style distribution is not just that it easily provides a whole bunch of useful modules - but that it *highlights* which modules are the community blessed best of breed. At the moment if a new user wants to work out how to achieve a particular task (work with images for example) they have to google around and try and work out what the right module to use is. For some problem domains there are a host of modules on PyPI many of which are unmaintained, immature or simply rubbish. A standardised solution makes choosing solutions for common problems *dramatically* easier, and may save people much heartache and frustration. For that to work though it needs to be well curated and genuinely have the substantial backing of the Python development community. All the best, Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
Lennart Regebro writes:
If licensing is a problem I guess you'd need to have permission to
relicense them all to the Python license,
Licensing compatibility is only a problem for copyleft, but most
copyleft licenses have mere aggregation is not derivation clauses.
Corporate concern about *knowing* what the license is, is a problem.
The XEmacs experience I've referred to elsewhere doesn't apply because
all our stuff is GPL, and therefore all our stuff has to be GPL. :-(
It's not obvious to me what the resolution is, although lots of
distributions now have some way to find out what licenses are. GCC
(and soon GNU Emacs) even have a way to check GPL-compatibility at
runtime (inspired by the Linux kernel feature, maybe?)
Perhaps the sumo infrastructure could provide a license-ok-or-fatal
feature. Eg, the application would do something like
sumo_ok_licenses = ['gplv2','bsd','microsoft_eula']
and the sumo version of the package's __init.py__ would do
sumo_check_my_license('artistic')
and raise LicenseError if it's not in sumo_ok_licenses. In theory it
might be able to do more complex stuff like keep track of declared
licenses and barf if they're incompatible.
This scheme probably doesn't save lawyer time. The lawyers would
still have to go over the actual packages to make sure the licenses
are what they say etc. before going into distribution. Its selling
point is that the developers would be warned of problems that need
corporate legal's attention early in 90% of the cases, thus not
wasting developer time on using packages that were non-starters
because of license issues.
which would be problematic. But otherwise having a team of people
overseeing and bundling all this might not be that much work, and
you'd avoid the bloat by not installing all of it. :-)
As I've argued elsewhere, bloat is good, for some purposes.
Or would this not fool the company trolls?
It will satisfy some, and not others, in my experience, described
elsewhere.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
Michael Foord writes: To my mind one of the most important benefits of a sumo style distribution is not just that it easily provides a whole bunch of useful modules - but that it *highlights* which modules are the community blessed best of breed. That has several problems. (1) There is a lot of overlap with the mission of the stdlib, and I think confusion over roles would be quite costly. (2) As the stdlib demonstrates, picking winners is expensive. I greatly doubt that running *two* such processes is worthwhile. (3) Very often there is no best of breed. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On 27 May 2010 16:56, Stephen J. Turnbull step...@xemacs.org wrote: We'll just have to agree to disagree, then. Plenty of evidence has been provided; it just doesn't happen to apply to you. Fine, but I wish you'd make the to me part explicit, because I know that it does apply to others, many of them, from their personal testimony, both related to XEmacs and to Python. Sorry, you're right. There's a very strong to me in all of this, but I more or less assumed it was obvious, as I was originally responding to comments implying that a sumo distribution was a solution to a problem I stated that I have. In trying to trim things, and keep things concise, I completely lost the context. My apologies. I wouldn't recommend building a production system on top of a sumo in any case. But (given resources to maintain multiple Python development installations) it is a good environment for experimentation, because not only batteries but screwdrivers and duct tape are supplied. That's an interesting perspective that I hadn't seen mentioned before. For experimentation, I'd *love* a sumo distribution as you describe. But I thought this whole discussion focussed around building production systems. For that, the stdlib's quality guarantees are a major benefit, and the costs of locating and validating appropriately high-quality external packages are (sometimes prohibitively) high. But I think I'm getting to the point where I'm adding more confusion than information, so I'll bow out of this discussion at this point. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Sumo
Le mercredi 26 mai 2010 à 13:19 +0100, Paul Moore a écrit : I'm not sure how a Sumo approach would work in practical terms, and this thread isn't really the place to discuss, but there's a couple of points I think are worth making: * For a Sumo distribution to make sense, some relatively substantial chunk of the standard library would need to be moved *out* to reside in the sumo distribution. Otherwise it's not really a sumo, just a couple of modules that nearly made it into the stdlib, at least for the near-to-medium term. This is not what I'm suggesting at all. The stdlib wouldn't shrink (well, we could dump outdated modules but that's a separate decision). A hypothetical Sumo distribution would be made of those more or less useful modules that many people (application or framework developers; for example, take a look at the dozens of direct and indirect dependencies TurboGears pulls in) need and install. The whole point is that it would *not* be supported by python-dev itself but by a separate group of people (such as you :-)). And it would have its own rules (surely more relaxed) over inclusion or deprecation delays, the ability to make compatibility-breaking changes, release timings, multiple obvious ways to do the same thing, etc. And it means it could really bundle a lot of third-party stuff: small helpers (things like the decorator module), event loops, template engines, network address abstractions, argument parsers, ORMs, UI toolkits, etc. (a side-effect would be that it could, if it works well, behave as a good intermediate stress test - a purgatory, if you want - for modules before they integrate the stdlib) If you want an existing analogy, you could look at EasyPHP. Or think of Python as the Gnome or KDE project (consistent and aiming at providing the most important everyday tools, but quite focused), and Sumo as an entire distribution of disparate Linux GUI apps. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On Wed, May 26, 2010 at 5:46 AM, Antoine Pitrou solip...@pitrou.net wrote: Le mercredi 26 mai 2010 à 13:19 +0100, Paul Moore a écrit : I'm not sure how a Sumo approach would work in practical terms, and this thread isn't really the place to discuss, but there's a couple of points I think are worth making: * For a Sumo distribution to make sense, some relatively substantial chunk of the standard library would need to be moved *out* to reside in the sumo distribution. Otherwise it's not really a sumo, just a couple of modules that nearly made it into the stdlib, at least for the near-to-medium term. This is not what I'm suggesting at all. The stdlib wouldn't shrink (well, we could dump outdated modules but that's a separate decision). A hypothetical Sumo distribution would be made of those more or less useful modules that many people (application or framework developers; for example, take a look at the dozens of direct and indirect dependencies TurboGears pulls in) need and install. The whole point is that it would *not* be supported by python-dev itself but by a separate group of people (such as you :-)). And it would have its own rules (surely more relaxed) over inclusion or deprecation delays, the ability to make compatibility-breaking changes, release timings, multiple obvious ways to do the same thing, etc. And it means it could really bundle a lot of third-party stuff: small helpers (things like the decorator module), event loops, template engines, network address abstractions, argument parsers, ORMs, UI toolkits, etc. (a side-effect would be that it could, if it works well, behave as a good intermediate stress test - a purgatory, if you want - for modules before they integrate the stdlib) If you want an existing analogy, you could look at EasyPHP. Or think of Python as the Gnome or KDE project (consistent and aiming at providing the most important everyday tools, but quite focused), and Sumo as an entire distribution of disparate Linux GUI apps. Regards Antoine. I'd also point out that creating a sumo distribution would focus attention on the need to port those libraries which were a part of it to python3, which would help to weaken the argument that there aren't any packages written for it. Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On 26 May 2010 13:46, Antoine Pitrou solip...@pitrou.net wrote: This is not what I'm suggesting at all. The stdlib wouldn't shrink (well, we could dump outdated modules but that's a separate decision). Ah, OK. In that case, I see the argument for a Sumo distribution as weak for a different reason - for general use, the standard library is (nearly!) sufficient, and ignoring specialised use cases, there aren't enough generally useful modules to warrant a Sumo distribution (you'd essentially be talking about stuff that nearly made it into the stdlib, and there's not a huge amount of that). Specialised distributions are another matter - I can see a web stack distribution comprising your TurboGears example (or should it be Django, or...?). Enthought essentially do that for a Scientific Python distribution. There could easily be others. But a general purpose Sumo distribution *on top of* the stdlib? I'm skeptical. (Personally, my essential extras are pywin32, cx_Oracle and that's about it - futures might make it if it doesn't get into the stdlib, but that's about all). I'm genuinely struggling to see how a Sumo distribution ever comes into being under your proposal. There's no evidence that anyone wants it (otherwise it would have been created by now!!) and until it exists, it's not a plausible place to put modules that don't make it into the stdlib. So (unless I'm missing something) your argument seems to be that if enough good stuff is rejected for stdlib inclusion, this will prompt the people who wanted that stuff included to create a sumo distribution, which addresses the too many dependencies is bad argument for inclusion in the stdlib. That sounds like a suspiciously circular argument to me... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
Le mercredi 26 mai 2010 à 23:41 +0100, Paul Moore a écrit : But a general purpose Sumo distribution *on top of* the stdlib? I'm skeptical. (Personally, my essential extras are pywin32, cx_Oracle and that's about it - futures might make it if it doesn't get into the stdlib, but that's about all). Well, unless you are short on megabytes or on download bandwidth, would you really care to get some modules you never use? (there are probably some in the stdlib too!) I'm genuinely struggling to see how a Sumo distribution ever comes into being under your proposal. There's no evidence that anyone wants it (otherwise it would have been created by now!!) and until it exists, it's not a plausible place to put modules that don't make it into the stdlib. I don't think all package owners dream of putting their software in the stdlib. It's likely some don't care, and it's likely some would actively refuse it (because e.g. they don't want to lose control). So the suggestion is not to somehow salvage packages which don't make it into the stdlib, but to build a broader distribution of packages without necessarily having people bow to the constraints of stdlib inclusion. Of course, I agree with you that someone has to do it if they want it to happen :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On Wed, May 26, 2010 at 3:41 PM, Paul Moore p.f.mo...@gmail.com wrote: On 26 May 2010 13:46, Antoine Pitrou solip...@pitrou.net wrote: This is not what I'm suggesting at all. The stdlib wouldn't shrink (well, we could dump outdated modules but that's a separate decision). Ah, OK. In that case, I see the argument for a Sumo distribution as weak for a different reason - for general use, the standard library is (nearly!) sufficient, and ignoring specialised use cases, there aren't enough generally useful modules to warrant a Sumo distribution (you'd essentially be talking about stuff that nearly made it into the stdlib, and there's not a huge amount of that). Specialised distributions are another matter - I can see a web stack distribution comprising your TurboGears example (or should it be Django, or...?). Enthought essentially do that for a Scientific Python distribution. There could easily be others. But a general purpose Sumo distribution *on top of* the stdlib? I'm skeptical. (Personally, my essential extras are pywin32, cx_Oracle and that's about it - futures might make it if it doesn't get into the stdlib, but that's about all). I'm not clear, you seem to be arguing that there's a market for many augmented python distributions but not one. Why not just have one that includes the best from each domain? I'm genuinely struggling to see how a Sumo distribution ever comes into being under your proposal. There's no evidence that anyone wants it (otherwise it would have been created by now!!) Everything worth making has already been made? and until it exists, it's not a plausible place to put modules that don't make it into the stdlib. Of course its implausible to put something somewhere that doesn't exist... until it does. So (unless I'm missing something) your argument seems to be that if enough good stuff is rejected for stdlib inclusion, this will prompt the people who wanted that stuff included to create a sumo distribution, which addresses the too many dependencies is bad argument for inclusion in the stdlib. That sounds like a suspiciously circular argument to me... I'd say rather that there are a large number of specialized tools which aren't individually popular enough to be included in Python, but which when taken together greatly increase its utility, and that sumo offers a way to provide that additional utility to python's users without forcing python core devs to shoulder the maintenance burden. Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On 27/05/10 09:11, geremy condra wrote: Specialised distributions are another matter - I can see a web stack distribution comprising your TurboGears example (or should it be Django, or...?). Enthought essentially do that for a Scientific Python distribution. There could easily be others. But a general purpose Sumo distribution *on top of* the stdlib? I'm skeptical. (Personally, my essential extras are pywin32, cx_Oracle and that's about it - futures might make it if it doesn't get into the stdlib, but that's about all). I'm not clear, you seem to be arguing that there's a market for many augmented python distributions but not one. Why not just have one that includes the best from each domain? Because scientists, financial analysts, web designers, etc all have different needs. A targeted distribution like Scientific Python will include nearly all the stuff a scientist is likely to need, but a financial analyst or web designer would find it lacking. As Paul points out, the current size of the set of modules that are sufficiently general purpose and of high enough quality to qualify for python-dev's blessing, but wouldn't be suitable for inclusion in the normal standard library is fairly small. Particular when most developers are able to get sufficiently valuable modules from PyPI if they genuinely need them. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
On Wed, May 26, 2010 at 4:57 PM, Nick Coghlan ncogh...@gmail.com wrote: On 27/05/10 09:11, geremy condra wrote: Specialised distributions are another matter - I can see a web stack distribution comprising your TurboGears example (or should it be Django, or...?). Enthought essentially do that for a Scientific Python distribution. There could easily be others. But a general purpose Sumo distribution *on top of* the stdlib? I'm skeptical. (Personally, my essential extras are pywin32, cx_Oracle and that's about it - futures might make it if it doesn't get into the stdlib, but that's about all). I'm not clear, you seem to be arguing that there's a market for many augmented python distributions but not one. Why not just have one that includes the best from each domain? 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. A targeted distribution like Scientific Python will include nearly all the stuff a scientist is likely to need, but a financial analyst or web designer would find it lacking. Seems like the same point as above, I might be missing something. As Paul points out, the current size of the set of modules that are sufficiently general purpose and of high enough quality to qualify for python-dev's blessing, but wouldn't be suitable for inclusion in the normal standard library is fairly small. Particular when most developers are able to get sufficiently valuable modules from PyPI if they genuinely need them. Seems like the point is not to focus on the general purpose ones, but rather to include domain or task specific libraries, and libraries that are close to (but not at) the level where they would be considered for inclusion. Geremy Condra ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
At 11:41 PM 5/26/2010 +0100, Paul Moore wrote: I'm genuinely struggling to see how a Sumo distribution ever comes into being under your proposal. There's no evidence that anyone wants it (otherwise it would have been created by now!!) Actually, sumo distributions *have* been created; it's just that there are so *many* of them: * Linux distributions * BSD Mac ports systems * ActivePython, the Enthought Distribution, etc. * certain distutils extensions that I shall not name When the idea of sumo distributions were first being batted around (10-12 years ago?), I'm not sure even *distutils* existed yet, let alone any of this other stuff. I mean, yeah, the port systems and distros existed, but their coverage wasn't nearly as good as it is today. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sumo
Hello, sorry to interrupt your discussion but.. On Thu, May 27, 2010 at 04:09, Yaniv Aknin ya...@aknin.name wrote: 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'. please note that the huge bunch of work for Python third-party modules is done in *Debian* and Ubuntu just takes those packages without advertise enough where they come from and who did the work (and not the merchandizing only). 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. mh? Debian was not in present in 1999? Debian started in 1993 (dpkg in 1994 and apt-get in 1998) while ubuntu only in mid-2000 as a layer over Debian packages (and hiring several Debian Developers for its core positions). Also, let me remind you that transition to Python 2.6 was a huge mess for Ubuntu, where several packages were just left broken (f.e. failing unit tests were disabled to make the package build...) and only now that Debian started to migrate to 2.6 too, you can see a flow of packages that works for 2.6 too coming to Ubuntu. Debian can be slow, but we care about quality. End of give credit where it's due post :) Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
