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

Donald Stufft donald at stufft.io
Wed May 27 21:03:52 CEST 2015



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.

This means that people who want/need a comprehensive standard library can get the Platform edition of the runtime which will function similar to the standard library of a language. However, if they run into some critical feature they need or a bug fix, they can selectively choose to step outside of that preset package versions and install a newer version of one of the bundled software. Of course they can install non-bundled software as well.

As far as Python is concerned, while I think the above model is better in the general sense, I think that it’s probably too late to switch to that, the history of having a big standard library goes back pretty far and a lot of people and processes depend on it. We’re also still trying to heal the rift that 3.x created, and creating a new rift is probably not the most effective use of time. It’s also the case (though we’re working to make it less true) that our packaging tools still can routinely run into problems that would make me uncomfortable using them for this approach.

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




More information about the Python-ideas mailing list