[Distutils] Name the software! Package quality tester.

P.J. Eby pje at telecommunity.com
Wed Mar 9 17:43:59 CET 2011

At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote:
>They certainly aren't "projects" in any sense that most people would

I don't follow you.  Sourceforge hosts projects.  Freshmeat indexes 
projects. Mozdev.org hosts projects.  The Apache Foundation hosts 
projects.  "Project", IOW, is *exactly* the word people use for these 
things, in the larger world of software, and that's precisely why I 
chose it for my original terminology proposal.

Many PyPI listings also only describe a project, in the sense that 
there is no release information at all, or the code is only available 
via a revision control system, etc.

>The term "project" has has never stuck, despite being discussed

It's only been discussed here, on this list.  It hasn't been put in 
official documentation, or really blessed by anybody.  When it has 
been discussed, it's been considered a reasonable name, and when 
people have needed to make the distinction, they've tended to use it.

The primary reason it hasn't caught on in a larger sense is that 
people don't know about it, and have no motivation to learn it unless 
they end up in a situation where the distinction makes a difference...

And let's face it, it really only makes a difference if you are 
creating some kind of packaging or distribution tool, or if you have 
a corner case of using one.

>I think given the historical use of the term "package" it
>was reasonable to find another term.  OK, we tried. It didn't work.

I don't think that's an accurate assessment on two points.  First, 
"we" didn't try -- *I* did.  (It's possible that someone else has 
promoted it, but I don't recall any instances of that.)

So, there actually being a "we" behind it -- where "we" includes an 
approved PEP, documentation, etc., would be helpful.

Second, I don't think it's accurate to say "it didn't work".  It's 
not like people who need the distinction have objected to the word or 
proposed any alternatives.

>We can pretent that if we work hard enough, we can make people adopt
>our confusing terminology.  Good luck with that.

No matter which way we go (assuming there aren't any other 
alternatives), we will be trying to get some group of people to 
change their terminology.  I'm just pointing out that the group that 
would need to change to use "project" is both smaller *and* 
inherently more motivated to change their usage, than the group that 
would need to replace "package" with "module".

Thus, if getting people to use "project" is an uphill battle, getting 
people to stop using "package" is going to be a much higher vertical 
cliff.  ;-)

For one thing, if the distutils documentation simply starts out like:

"If you want to distribute your work to the larger Python community, 
you need to create a project for it.  In practical terms, this means 
having a directory with a setup.py and the code, data, or 
documentation you wish to distribute.  Your project will also need a 
unique name, if you want to make it accessible to others via the 
Python Project Index (PyPI)."  (replace setup.py w/setup.cfg for 
distutils2, of course)

This usage of project also maps onto common IDE usage of the term 
project -- a directory of stuff that you're going to edit and build.

And, it immediately introduces the term to a superset of the audience 
that will need to know it.  Having PyPI describe its contents as 
"projects" is pretty much the other half of the indoctrination needed.

In contrast, to make the package->module change, you'd have to not 
only change the official language reference and tutorial, but also 
every third-party book or tutorial about Python.

Sure, some of those third party references would also exist for 
"package" as "project", but that's simply an *imprecise* usage, 
rather than an *incorrect* one.

More information about the Distutils-SIG mailing list