At 07:06 AM 3/9/2011 -0500, Jim Fulton wrote:
They certainly aren't "projects" in any sense that most people would
understand.
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
repeatedly.
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.
_______________________________________________
Distutils-SIG maillist - [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig
