Re: [Distutils] Name the software! Package quality tester.
On Tue, Mar 8, 2011 at 6:00 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Jim Fulton wrote: I question whether that distinction is important, but if and when it is, then we could use an adjective to clarify. Under the hood, the object we call packages today are just modules. I think the fact that we used the word package in the first place testifies that it *is* important -- otherwise we wouldn't have invented the term. We invented the term long before distutils was invented and without much, of any, consideration for software distribution. Just because we've historiaclly uses a term, doesn't mean it's a good term. The word package covers much more than just the module object that comes into being when you import it. It also implies the associated directory structure, extra import facilities and mechanisms, etc. It's not just a minor variation on the concept of a module. I agree to disagree. :) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Tue, Mar 8, 2011 at 12:26 PM, P.J. Eby p...@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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
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 - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
On Mar 9, 2011, at 7:06 AM, Jim Fulton j...@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.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
FWIW, when I've been writing docs or answering packaging questions and trying to use the approved, unambiguous terminology, using project for thing with a PyPI page has never been a problem; I've had much more difficulty in using distribution as the term for a zipfile or tarball or egg that you download (also a package in colloquial usage). I always have to awkwardly qualify it with distribution tarball or project distribution due to the conflict with Linux distributions. Carl ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
They certainly aren't projects in any sense that most people would understand. I don't follow you. Maybe we have lost the context here, but I think I agree with Jim. Even though PyPI hosts projects, they (the files you download) aren't projects - they are distributions or packages. Regards, Martin ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
At 10:22 PM 3/9/2011 -0500, Martin v. Löwis wrote: They certainly aren't projects in any sense that most people would understand. I don't follow you. Maybe we have lost the context here, but I think I agree with Jim. Even though PyPI hosts projects, they (the files you download) aren't projects - they are distributions or packages. I think you have lost the context; here, project refers to the thing that you have versions of, which distributions in turn are discrete manifestations of. That is, a project has releases which has distributions. For example, http://pypi.python.org/pypi/Trac is a PyPI page for a project, http://pypi.python.org/pypi/Trac/0.12.2 is the PyPI page for release 0.12.2 of that project, and http://pypi.python.org/packages/source/T/Trac/Trac-0.12.2.tar.gz is one of the distributions available for that release of that project. PyPI allows one to host a project that has neither releases nor distributions, so in that sense it is certainly an index of projects, in much the same way that ASF, SourceForge, MozDev, and others are. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
