At 08:08 AM 3/10/2011 -0500, Jim Fulton wrote:
I really should let this rest ... really
I notice you seem to have already let rest defending your proposal,
as opposed to opposing mine. ;-)
That is, I don't see where you've included any counterargument for
why convincing people to *stop* using package for python package
isn't going to be a lot harder than simply *adding* the term
project to existing docs, via simple explanations like this one:
If you would like to distribute your python package or module, you
need to create a project. A project consists of a directory
containing the package(s) or module(s) you want to distribute, along
with a setup.py/.cfg, specifying the project's name, current version
number, and other information. If you wish to distribute your
package via PyPI, then you must choose a unique project name and
register it. If you are only distributing one module or package,
you can name the project after it, as long as it doesn't conflict
with any other project names already registered on PyPI.
Context-specific explanations like this are easy to give, at a place
where the recipient of the explanation *wants* to learn something.
In contrast, to convince everybody in the world to replace package
with module, you must send out a constant broadcast to people who
don't really care.
(your other points are addressed below)
On Wed, Mar 9, 2011 at 11:43 AM, P.J. Eby p...@telecommunity.com wrote:
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.
But the things in PyPI are not projects. Projects have bug trackers,
and mailing lists, and source code repositories.
And which of those things have to be hosted on the same site as the
project's index page? Freshmeat, for example, is not a project
*hosting* system, it's a project *index*. PyPI is in that sense, a
project index. Some index pages may link to all the stuff associated
with that project, some may not.
(i.e. the set of all possible project features is not equal to the
intersection of all projects' actual features: some project have
mailing lists and not bug trackers, and vice versa. This does not
make them non-projects.)
Projects are organizations of people -- not software distributions.
I'm an organization of people; am I a project? No, the various
things I have listed on PyPI are my projects, and I distribute
releases of them.
The things in PyPI that you call projects are things that get
produced by projects. There isn't a buildout.recipe.egg
project. buildout.recipe.egg is just a um packaging of some software
components. It's not a project in any usual sense of the word.
I don't get that. You work on it, and it is distinct from other
works. That makes it a project.
No. End users need to know about this. They need to know what these
names mean and that the package name (distutils) or project name
(setuptools) doesn't imply that the distribution will provide a python
package of the same name. Trust me on this. Users care about this.
Actually, I believe distutils calls it a distribution name, but I
could be wrong about that. ;-)
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)
It does? Where? Can you give a link? I don't see this text anywhere.
Of course not; it was a proposal for a hypothetical
introduction. That's why it says if up there. ;-)
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.
That use of project is equivalent to working directory and not
relevant, IMO.
Huh? In an IDE, a project is a thing you build and distribute,
usually with source control. It's distinct from other projects, and
it has a name. It is usually not tied to a specific code unit such
as a module or package (regardless of what the code units of the
relevant programming language are called). It has additional
metadata, over and above the actual code units, and possibly includes
non-code resources such as documentation, data, images, etc.
IOW, it's *exactly* the sort of project we're talking about
here. So, the term project is
