<br><br>On Friday, August 14, 2015 at 12:19:44 AM UTC+5:30, Alex Grönholm wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">13.08.2015, 20:35, Donald Stufft kirjoitti:<br><br>   <br>> One possible thing to look at for prior art, is what Haskell does. They don’t have a bunch of ensure* modules or anything like it, instead they have their compiler (which is like “Haskell Core” and then on top of that they layer a bunch of libraries (Called “Haskell Platform”). This platform releases every ~6 months and just includes something like 40 different libraries with it that represent common development tools and widely used libraries [1].<br>><br>> So I guess my question is, instead of continuing down a path where we add more ensure* style modules to the standard library, why not do something similar and have “Python the Language” and “The Python Platform”, and the platform would be the Python language + N “important” or “popular” packages. This could release on a quicker release schedule than Python itself (since it would really be more like a meta package than anything that itself got developed) and would give the ability to ship things like this without the problems that we’ve had with ensurepip. From a downstream perspective they would just package all of this stuff as normal and it would just be available as normal. We could even publish a metapackage on PyPI that had no code of it’s own, but existed simply to list all of the platform packages as dependencies (with ==) and then people could easily depend on the Python “platform” in their own code.<br>><br>> This would essentially involve someone(s) needing to be the gatekeeper of which libraries become part of the Python platform, some small packaging shims to handle the metapackage on PyPI, and then the installer stuff for OSX and Windows (probably nothing for other OSs? Or maybe a tarball? I don’t know).<br>Amen to this. This is EXACTLY where I've hoped Python would go :)<br><br></blockquote><div><br>As an idea that's fine<br>As an actual example, Haskell's package system is more broken than most -- See<code> </code><a href="https://www.reddit.com/r/haskell/comments/2al3vx/how_do_you_avoid_the_cabal_hell/">cabal hell</a><br>In fact Haskell's package system is  ironically un-functional<br>Last I knew you can <span style="color: #000;" class="styled-by-prettify">'cabal install foo</span><code class="prettyprint"></code>'<br><br>You cant 'cabal uninstall foo' thereafter; only 'cabal unregister foo'<br>Or delete all haskell packages and start over!<br><br>That's like saying that after apt-get install foo the only way of undoing it is to reinstall linux<br><br>More generally large non-trivial systems -- not just languages like python, haskell, ruby etc, but even emacs, tex, eclipse, firefox etc -- have their own packaging systems.<br>These are all upstream of distro systems like apt/portage etc which are usually more stable, thoroughly thought out but by definition of downstream, somewhat stale.<br><br>It would be good if choices like increasing 'ensures' keep in mind the required symbiosis between these two packaging worlds.<br><br>Ideally -- somewhat utopian -- we can imagine a world of federated package management, where one could say<br><br><div class="prettyprint" style="background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><code class="prettyprint"><div class="subprettyprint"><span style="color: #800;" class="styled-by-prettify"># apt-get subsystem python install django</span></div></code></div><br><br>and apt gets django from Pypi rather than from debian/ubuntu repos<br></div>