[Python-ideas] Lib vs ( App | Project | ... )

[Nick Coghlan]

On 18 May 2016 at 16:38, Thomas Güttler <guettliml at thomas-guettler.de> 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-applications
>   - 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 at gmail.com   |   Brisbane, Australia