[Python-ideas] Increasing public package discoverability (was: Adding jsonschema to the standard library)

[Donald Stufft]

On May 27, 2015 at 5:50:55 PM, Andrew Barnert (abarnert at yahoo.com) wrote:
> On May 27, 2015, at 12:03, Donald Stufft wrote:
> >
> >> On May 27, 2015 at 2:57:54 PM, Demian Brecht (demianbrecht at gmail.com) wrote:
> >>
> >>> On May 27, 2015, at 11:46 AM, Paul Moore wrote:
> >>>
> >>> So it's unlikely to ever happen, because it would cripple Python for a
> >>> non-trivial group of its users.
> >>
> >> I’m just throwing ideas at the wall here, but would it not be possible to release two  
> versions,
> >> one for those who choose to use decentralized packages with out-of-band releases  
> and
> >> one with all “recommended” packages bundled (obvious potential for version conflicts  
> >> and such aside)? If one of the prerequisites of a “recommended” package was that it’s  
> >> released under PSFL, I’m assuming there wouldn’t be any legal issues with going down  
> >> such a path? That way, you still get the ability to decentralize the library, but don’t  
> >> alienate the user base that can’t rely on pip?
> >
> >
> > I’m of the opinion that, given a brand new language, it makes more sense to have really  
> good packaging tools built in, but not to have a standard library. This you call “FooLang  
> Core” or something of the sort. Then you take the most popular or the best examples or whatever  
> criteria you want from the ecosystem around that and you bundle them all together so that  
> the third party packages essentially get preinstalled and you call that “FooLang Platform”  
> or something.
>  
> Dependencies are always going to be a problem. The best way to parse XML is lxml (and the  
> best way to parse HTML is BeautifulSoup plus lxml); does that mean that the Python Platform  
> requires libxml2? The best way to do numerical computing is with NumPy, and the best way  
> to build NumPy is with MKL on platforms where it exists, ATLAS on others; does that mean  
> the Python Platform requires MKL and/or ATLAS? The best way to build cross-platform  
> GUIs with desktop integration is PySide; does that mean the Python Platform requires  
> Qt? (One of the biggest portability problems for Python in practice has always been Tcl/Tk;  
> Qt would be much worse.)
>  
> You could look at it as something like the core plus distributions model used in OS's.  
> FreeBSD has a core and ports; there's a simple rule for what's in core (a complete POSIX  
> system plus enough to build ports, nothing else), and the practicality-vs.-purity  
> decisions for how to apply that to real-life problems isn't that hard. But Linux took  
> a different approach: it's just a kernel, and everything else--libc, the ports system,  
> etc.--can be swapped out. There is no official distribution; at any given time in history,  
> there are 3-6 competing "major distributions", dozens of others based on them, and some  
> "special-case" distros like ucLinux or Android. And that means different distros can  
> make different decisions on what dependencies are acceptable--include packages that  
> only run on x86, or accept some corporate quasi-open-source license or closed-source  
> blob.
>  
> Python seems to have fallen into a place halfway between the two. The stdlib is closer  
> to FreeBSD core than to Linux. On the other hand, while many people start with the official  
> stdlib and use pip to expand on it, there are third-party distributions competing to  
> provide more useful or better-organized batteries than the official version, plus  
> custom distributions that come with some OS distros (e.g., Apple includes PyObjC with  
> theirs), and special things like Kivy.
>  
> That doesn't seem to have caused any harm, and may have caused a lot of benefit. While Python  
> may not have found the perfect sweet spot, what it found isn't that bad. And the way it continues  
> to evolve isn't that bad. If you could go back in time to 2010 and come up with a grand five-year  
> plan for how the stdlib, core distribution, and third-party ecosystem should be better,  
> how much different would Python be today?
>  
>  

It certainly doesn’t require you to add something to the “Platform” for every topic either. You can still be conservative in what you include in the “Platform” based on how many people are likely to need/want it and what sort of dependency or building impact it has on actually building out the full Platform.

---  
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA