[Python-ideas] More "ensure*" packages

[Rustom Mody]

On Friday, August 14, 2015 at 12:19:44 AM UTC+5:30, Alex Grönholm wrote:
>
> 13.08.2015, 20:35, Donald Stufft kirjoitti:
>
>    
> > 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].
> >
> > 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.
> >
> > 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).
> Amen to this. This is EXACTLY where I've hoped Python would go :)
>
>
As an idea that's fine
As an actual example, Haskell's package system is more broken than most -- 
See cabal hell 
<https://www.reddit.com/r/haskell/comments/2al3vx/how_do_you_avoid_the_cabal_hell/>
In fact Haskell's package system is ironically un-functional
Last I knew you can 'cabal install foo'

You cant 'cabal uninstall foo' thereafter; only 'cabal unregister foo'
Or delete all haskell packages and start over!

That's like saying that after apt-get install foo the only way of undoing 
it is to reinstall linux

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

It would be good if choices like increasing 'ensures' keep in mind the 
required symbiosis between these two packaging worlds.

Ideally -- somewhat utopian -- we can imagine a world of federated package 
management, where one could say

# apt-get subsystem python install django


and apt gets django from Pypi rather than from debian/ubuntu repos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150815/57f342b0/attachment-0001.html>