Re: [Distutils] Name the software! Package quality tester.
At 05:18 PM 3/7/2011 -0500, Jim Fulton wrote:
If what we now call "packages" were called "modules", then we could start using the term "package" the way everyone else does. I think lots of people would be less confused.
It seems to me that in order to make that change, you have to get more people to change their terminology, since the set of people who need to refer to package[module] is larger than the set of people who need to refer to package[project]. (There is also a larger body of documentation associated with package[module].) IOW, I think this proposal is a heavy uphill battle, both in the number of people to be convinced and the amount of documentation. In addition, the people who are calling a project a package can more easily understand the need to call it a project, than the people who are calling a package a package, will understand the need to call it a module. ;-)
Otherwise, I prefer we try hard to use the precise definitions above. This topic can be confusing enough without making it more so through sloppy terminology.
I think that this approach is more achievable: it requires only an official blessing, a relatively small amount of documentation to be changed, and the renaming of PyPI et al. (i.e. "Python Projects Index", projects.python.org, etc.) ("Projects Index" is a better name anyway, since some things on PyPI are not packages at all but applications, scripts, modules, plugins, etc.)
On Tue, Mar 8, 2011 at 12:26 PM, P.J. Eby <pje@telecommunity.com> wrote:
At 05:18 PM 3/7/2011 -0500, Jim Fulton wrote:
If what we now call "packages" were called "modules", then we could start using the term "package" the way everyone else does. I think lots of people would be less confused.
It seems to me that in order to make that change, you have to get more people to change their terminology, since the set of people who need to refer to package[module] is larger than the set of people who need to refer to package[project]. (There is also a larger body of documentation associated with package[module].)
IOW, I think this proposal is a heavy uphill battle, both in the number of people to be convinced and the amount of documentation. In addition, the people who are calling a project a package can more easily understand the need to call it a project, than the people who are calling a package a package, will understand the need to call it a module. ;-)
Otherwise, I prefer we try hard to use the precise definitions above. This topic can be confusing enough without making it more so through sloppy terminology.
I think that this approach is more achievable: it requires only an official blessing, a relatively small amount of documentation to be changed, and the renaming of PyPI et al. (i.e. "Python Projects Index", projects.python.org, etc.)
The term "project" has has never stuck, despite being discussed repeatedly. I think given the historical use of the term "package" it was reasonable to find another term. OK, we tried. It didn't work. We can pretent that if we work hard enough, we can make people adopt our confusing terminology. Good luck with that.
("Projects Index" is a better name anyway, since some things on PyPI are not packages at all but applications, scripts, modules, plugins, etc.)
They aren't "packages" a according to current Python definition of the term. They *are* packages according to the common usage within the industry. They certainly aren't "projects" in any sense that most people would understand. They are arguably products of projects. Of course, the term "product" has negative connotations for some folks. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton
On Mar 9, 2011, at 7:06 AM, Jim Fulton <jim@zope.com> wrote:
They certainly aren't "projects" in any sense that most people would understand. They are arguably products of projects. Of course, the term "product" has negative connotations for some folks.
Not for everybody! As far as I am concerned, the whole Python packaging ecosystem (not to mention every Twisted-based plugin mechanism and extension point) is merely trying to re-ascend to the lofty heights once occupied by the beautiful completeness and usability of the zope2 "product" architecture :). (Not kidding! I loved those things.)
participants (3)
-
Glyph Lefkowitz -
Jim Fulton -
P.J. Eby