On Tue, May 17, 2016 at 11:38 PM, Thomas Güttler < guettliml@thomas-guettler.de> wrote:

AFAIK there can only be **one** sitecustomize.py. I think the docs should be able to have a term for the thing which contains/provides this file.

uhm, the file system? it's a single file, and while a python module technically, it acts as a configuration file. so not a library, or a system or a package, or....

The current vacuum gets filled with a lot of different terms meaning the same thing. This does not hurt, but still I **feel** it would help to have an agreement on a term.

sure, but where, how, etc does one gain consensus? since this all overlaps with non-python software development, I do'nt htink we'll ever get a consensus.

The closest we get is the PyPA/distutils-sig consensus that software

...

is developed by and as projects (covering libraries, applications, and assorted other endeavours): https://packaging.python.org/en/latest/glossary/#term-project

Thank you Nick, for providing this link. I hope your are not the author of this text. This is no definition according to my point of view. I read it, and don't get it.

I"m sure PRs are considered :-)

Example: I think "django" is a project according to this definition.

I think it's a package. An application built with Django is a Project. See -- no consensus :-)

The install_requires vs requirements.txt question is covered as its

...

own topic, without introducing any particular terminology: https://packaging.python.org/en/latest/requirements/

It is hard to cover the meaning of requirements.txt if there is no common term to name the container which contains it :-)

I think this all comes down to guidelines and suggestions -- each developer is going to need to figure out what best fits their needs. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov

On 18 May 2016 at 16:38, Thomas Güttler wrote:

Am 17.05.2016 um 15:20 schrieb Nick Coghlan:

...

Covering general principles of software engineering and the many and varied terms used for different kinds of software aggregation is *way* outside the scope of the Python language and standard library docs :)

AFAIK there can only be **one** sitecustomize.py. I think the docs should be able to have a term for the thing which contains/provides this file.

`sitecustomize.py`, if provided at all, tends to be scoped to the Python installation. Since most (all?) installers don't provide it by default, it typically shows up as part of an organisation specific Standard Operating Environment, although you can technically add it to any virtual environment.

The current vacuum gets filled with a lot of different terms meaning the same thing. This does not hurt, but still I **feel** it would help to have an agreement on a term.

Agreement on terminology for pre-existing concepts can't be forced, only observed as an emergent phenomenon (one of the most prominent Python-specific examples of that being the multi-year effort to get people to stop using "package" for both import packages and distribution packages, before we finally conceded defeat and documented the ambiguity, rather than continuing to try to eliminate it) Real world categories are fuzzy, so the apparent precision of software development starts to break down once we start talking about the higher level assemblies that blur the lines between the software being developed and the collections of humans doing the development. (For one of the classic cognitive science examples of category fuzziness, first ask "What is a chair?". Then, whatever definition people give, present counter-examples that challenge their definition: "Is an overturned milk crate a chair?", "Is a cut log a chair?", "Is a foot stool a chair?", "Is a park bench a chair?", "What about rocking chairs?", "What about armchairs?", "What about desk chairs?", "What about folding chairs?").

...

The closest we get is the PyPA/distutils-sig consensus that software is developed by and as projects (covering libraries, applications, and assorted other endeavours): https://packaging.python.org/en/latest/glossary/#term-project

Thank you Nick, for providing this link. I hope your are not the author of this text. This is no definition according to my point of view. I read it, and don't get it. Example: I think "django" is a project according to this definition.

Yes, Django is a project.

But I search a term for the thing containing:

settings.py sitecustomize.py logging-config, ....

These are also projects: https://docs.djangoproject.com/en/1.9/ref/django-admin/#startproject Whether a given Django project is also a project in the PyPA sense will depend on how it is published. This is why Sphinx has glossary support - so projects can clearly define otherwise ambiguous terms in *their particular context*.

...

The install_requires vs requirements.txt question is covered as its own topic, without introducing any particular terminology: https://packaging.python.org/en/latest/requirements/

It is hard to cover the meaning of requirements.txt if there is no common term to name the container which contains it :-)

The syntactic meaning of requirements.txt is straightforward: it's a series of installation commands for pip. The semantic meaning is context dependent - some projects will use it to express approximate runtime requirements (more like the recommended way of using install_requires in setup.py), while others will use it as a complete environment specification (e.g. by using a tool like pip-compile).

The above link calls it "complete python environment".

Up to now I found these terms:

- Project https://docs.djangoproject.com/en/1.8/ref/applications/#projects-and-applica... - Application https://caremad.io/2013/07/setup-vs-requirement/ - site https://docs.python.org/3/library/site.html - complete python environment https://packaging.python.org/en/latest/requirements/

I guess there are more. "Standards are great: Everyone should have one"

Is this the way you want it to be?

What I want has nothing to do with it - the emergence of ambiguity that requires context-specific clarification of terms is just a raw fact about human behaviour in the absence of centralised authoritarian control.

I see no agreement on the name for the concrete installation holding all those nice python libraries.

Correct, because there isn't one. Where the difference in perspective arises is that you appear to believe that python-dev has the collective power to define one, but we don't. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Wed, May 18, 2016 at 08:38:43AM +0200, Thomas Güttler wrote:

I see no agreement on the name for the concrete installation holding all those nice python libraries.

I don't think you have made the case why we need such an agreement. What is the *actual problem* you are hoping to solve here? -- Steve