[Distutils] [Catalog-sig] packaging terminology confusion

Brad Allen bradallen137 at gmail.com
Sat Jan 9 19:47:06 CET 2010

On Sat, Jan 9, 2010 at 10:38 AM, P.J. Eby <pje at telecommunity.com> wrote:
> At 09:13 AM 1/9/2010 -0600, Brad Allen wrote:
>> On Fri, Jan 8, 2010 at 11:44 AM, P.J. Eby <pje at telecommunity.com> wrote:
>> >>
>> >> Yes, very much. I like 'parcel' better than 'project', partly because
>> >> it's not already overload with other contextual meanings.
>> >
>> > This is just another example of the degree of confusion around
>> > terminology
>> > here, because "parcel" isn't a substitute for "project": a "project" is
>> > something that you would release "parcels" *for*.
>> These two terms have yet to be formally adopted, so they can mean what
>> we want them to mean.
> You miss my point: the usage of "project" you were commenting on was not in
> reference to the same thing as your comment.  In the context of the thread,
> "project" was referring to "thing that has releases" and "parcel" was being
> used as a substitute for the existing term "distribution" or "module
> distribution".
> (And even if it's *me* who's confused here, the point still stands about the
> degree of confusion.  ;-) )
> Anyway, IMO "parcel" works great as a substitute for "distribution" (as it
> is a concrete term for a concrete thing) and not so great as a substitute
> for "project" (since a project isn't that concrete a thing and "parcel"
> therefore seems *too* concrete).

No, I am certainly the more confused party. I have not fully thought
through all the concepts under consideration here.

Up till now I've been thinking that we have been trying to come up
with the right name of a concrete thing: a directory containing a
setup.py, along with source code and resources needed to generate the
file in the 'dist' directory. That is why 'parcel' started to seem

Now I understand that your 'project' concept probably corresponds to
an entry in PyPI which is associated with multiple releases (each
release having a set of downloadable files available, formally called
'distributions' or 'module distributions', but informally called
'packages'.)  The word 'project' is not a suitable replacement for the
word 'package', because 'project' is a higher level abstract container
of releases, not a downloadable file containing a setup.py.

Back to the problem at hand: why is the term 'package' is so
ubiquitously used instead of 'module distribution', despite the
ambiguity? And what can the community do to reduce the ambiguity?

Here's a theory:

When you have a release ready, what do you do with it? You 'package'
it, of course. You don't 'project' it, and you don't 'parcel' it. What
is the result of the 'packaging' activity? It's a 'package' of course.

Thought of in this way, it's understandable why the term 'package'
keeps getting used despite well-meaning efforts to call it something
else, and names like 'module distribution' or a 'parcel' probably
won't catch on.

Maybe it's just wrong to call the __init__.py directories 'packages',
because they are really just a piece of what is getting packaged.
Also, in the physical world, a 'package' is a thing you distribute. Do
we ever distribute an __init__.py directory by its lonesome? No! It
doesn't have any packaging around it.

I am starting to feel twinges of animosity toward the use of the word
'package' for these barenaked, poor defenseless __init__.py
directories. Why can't we do a better job of defending our __init__.py
thingies from wrongful packaging terminology?

Frequently in the README of an entry in PyPI, I see instructions for
"installing this package".

Of course, the other concept is the entry in PyPI, which encompasses
multiple releases (but not necessarily all versions), though the UI
normally only displays the latest release. Normally the entry in PyPI
has docs stating "Installing this Package"

The concept which seems to be missing the right word is the directory
containing the setup.py and other resources needed to build a
distribution. Every time you change the version in the setup.py, it's
just a different version of the same thing.

I am have a

More information about the Distutils-SIG mailing list