[Import-SIG] PEP 382: Partial packages

[Nick Coghlan]

On Mon, Jul 11, 2011 at 8:30 AM, P.J. Eby <pje at telecommunity.com> wrote:
> I'm okay with some bikeshedding on the file extension, but unless somebody
> really comes up with a truly *excellent* replacement for "namespace
> package", I don't see much point to changing it.
>
> I will go ahead and throw in a few ideas, none of which I think are
> necessarily *excellent*, but which seem like they might work:
>
>  * multipart packages (packages that can be divided into separately
> installed/distributed parts)
>  * package families (a group of packages that share a "family name")
>  * organization packages (package whose purpose is to organize other
> packages, and/or indicate organizational authorship)
>  * partitioned packages (packages that can be divided into separately
> installed/distributed parts)
>
> Thoughts?

FWIW, +1 on "partitioned packages" as the term and either .pyp or
.pypart as the extension.

Why do I like partitioned packages?

1. It correctly emphasises the real purpose of this kind of package:
allowing a single namespace at the Python level to be cleanly split
into multiple partitions at the file distribution level. "namespace
packages" fails on this count.
2. It makes it clear that any given *piece* of the package can only be
correctly provided by one partition, as anything else results in a
collision within the package namespace. This is the only suggested
term that really conveys this aspect at all.
3. It doesn't have the same connotations of incompleteness that
plagues "partial packages"
4. It makes it clear that this is still just one package at the Python
level, which a term like "package families" would obscure.
5. It is agnostic as to the reasons *why* developers might want to
partition the namespace, whereas something like "organization
packages" assumes a great deal about how they will be used in
practice.

Regards,
Nick.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia