[stdlib-sig] Breaking out the stdlib

[Brett Cannon]

On Mon, Sep 14, 2009 at 12:19, Jesse Noller <jnoller at gmail.com> wrote:
> On Mon, Sep 14, 2009 at 3:11 PM, Brett Cannon <brett at python.org> wrote:
>> On Mon, Sep 14, 2009 at 11:56, Jesse Noller <jnoller at gmail.com> wrote:
>>> On Mon, Sep 14, 2009 at 2:54 PM, Barry Warsaw <barry at python.org> wrote:
>>>> On Sep 14, 2009, at 11:35 AM, Paul Moore wrote:
>>>>
>>>>> Please remember that some establishments have restrictions that mean
>>>>> that tools like easy_install or pip cannot be used. In locked-down
>>>>> corporate environments, python-full is potentially all that will be
>>>>> available (and maybe very specific "blessed" environment-specific 3rd
>>>>> party modules).
>>>>
>>>> Splitting things out for developers is not the same as keeping that split
>>>> visible for distributions, either via tarball, binary from us, or through
>>>> distros.  In fact, I'd venture to guess that most locked down establishments
>>>> are not going to be installing Python from us; they'll get it through their
>>>> operating system vendor (well, thank goodness I don't have to know what
>>>> locked down Windows users have to go through ;).
>>>>
>>>> Still, there's no reason why we couldn't ship sumo packages with all those
>>>> batteries included again.
>>>>
>>>> -Barry
>>>
>>> Yup; that was spelled out in the OP - I would like: core, stdlib,
>>> everything as 3 packages. 99% of people will download the 3rd.
>>
>> Just to toss in my opinion, I think the standard library should be
>> broken out in the VCS to make it very obvious what all Python VMs
>> should come with and work with, but I don't think we should package it
>> up for distribution separately. CPython should probably shift to
>> having a slightly less stranglehold on the standard library than it
>> has now. This would also help legitimize the other VMs.
>>
>> But I see no benefit for the general populace in having a version of
>> Python w/o a standard library. Anyone who has funky space requirements
>> can just do the leg work needed prune down the standard library to
>> what they need.
>>
>> -Brett
>>
>
> Yeah: Except for those people that means custom compiling an
> interpreter too. The tight coupling is just painful. When I want to
> trim the standard library, I should not have to hack the build
> scripts, compile an interpreter, etc, etc.
>
> I'm really strongly (duh) for massive decoupling between the two,
> especially within the build system.
>

Decoupling in the build system is a good idea and would naturally
happen if we broke out the standard library in the VCS.

> How is there any harm in offering 3 downloads? The obvious thing is to
> click on the big "get some pythons on" button which gets what we know
> as python today.
>
> Then there are two little buttons: get "just this" or "just that".

Because I don't want to have to start telling people "download the
full Python distribution, not the interpreter-only one; that's only
for those folk who want to stuff Python on an embedded device." That
seems silly. And you know some newbie will screw up, download only the
interpreter version and wonder why he can't import some module. The
amount of people who are going to screw up on what to download will
most likely be larger than the people who are going to save some time
downloading just the interpreter instead of having to tweak something
for an embedded device.

-Brett