[Python-ideas] Increasing public package discoverability

[Mark Lawrence]

On 27/05/2015 20: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.
>
> 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
>

Could Python 4 tear out the stdlib completely and go to pypi, to what I 
believe Nick Coghlan called stdlib+, or would this be A PEP Too Far, 
given the one or two minor issues over the move from Python 2 to Python 3?

Yes this is my very dry sense of humour working, but at the same time if 
it gets somebody thinking, which in turn gets somebody else thinking, 
then hopefully ideas come up which are practical and everybody benefits.

Just my £0.02p worth.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence