[Python-ideas] Lib vs ( App | Project | ... )
Thomas Güttler
a Library and a Application.
https://caremad.io/2013/07/setup-vs-requirement/
The term "Library" is well known - ok
But how to call the container for the libraries, the one thing providing the environment?
Donald Stufft uses the term "Application"
I would like an official term defined by the python docs.
What do you think?
Regards,
Thomas Güttler
--
Thomas Guettler http://www.thomas-guettler.de/
_______________________________________________
Python-ideas mailing list
Python...@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Nick Coghlan
> This blog post from Donald Stufft explains the difference between
> a Library and a Application.
>
> https://caremad.io/2013/07/setup-vs-requirement/
>
>
> The term "Library" is well known - ok
>
> But how to call the container for the libraries, the one thing providing the
> environment?
>
> Donald Stufft uses the term "Application"
>
> I would like an official term defined by the python docs.
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 :)
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
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/
Cheers,
Nick.
--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia
Steve Dower
Not sure that we need an official term, but the venv docs likely have or need a definition to work with.
Cheers,
Steve
Top-posted from my Windows Phone
From: Thomas Güttler
Sent: 5/17/2016 4:28
To: python-ideas
Subject: [Python-ideas] Lib vs ( App | Project | ... )
Thomas Güttler
Am 17.05.2016 um 15:20 schrieb Nick Coghlan:
> On 17 May 2016 at 21:09, Thomas Güttler <guet...@thomas-guettler.de> wrote:
>> This blog post from Donald Stufft explains the difference between
>> a Library and a Application.
>>
>> https://caremad.io/2013/07/setup-vs-requirement/
>>
>>
>> The term "Library" is well known - ok
>>
>> But how to call the container for the libraries, the one thing providing the
>> environment?
>>
>> Donald Stufft uses the term "Application"
>>
>> I would like an official term defined by the python docs.
>
> 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.
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.
> 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. But I search a term
for the thing containing:
settings.py
sitecustomize.py
logging-config, ....
> 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 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?
I see no agreement on the name for the concrete installation holding all those nice python libraries.
Regards,
Thomas Güttler
--
Thomas Guettler http://www.thomas-guettler.de/
Chris Barker
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.
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.
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.
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 :-)
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....@noaa.gov
Brett Cannon
Nick Coghlan
> 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 | ncog...@gmail.com | Brisbane, Australia
Stephen J. Turnbull
> I see no agreement on the name for the concrete installation
> holding all those nice python libraries.
I don't see how you could get it.
The "concrete installation" you mention is apparently is defined by
"holding all those nice python libraries" -- you make no mention of
requirements.txt or any of the other "marker" files you've talked
about. It's also unclear whether "concrete installation" includes
things like the Python distribution itself (even the operating
system), or perhaps things in site-packages but not the stdlib.
And that is the problem. The variety of "collections of libraries"
(some of which are singletons, others of which may be instantiated as
empty!) and accompanying configuration (if any) that a developer might
want denoted by the name you're looking for is pretty well infinite.
It's not going to be the same as the distribution, since those often
don't include configuration files (and does the "example.cfg" count?)
In any case it's large enough that we're going to get substantial
disagreement on the definition even before we try to choose a name.
Steve
Steven D'Aprano
> I see no agreement on the name for the concrete installation holding all
> those nice python libraries.
What is the *actual problem* you are hoping to solve here?
--
Steve
Thomas Güttler
> 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?
no segmentation fault.
But still I fell that there is something wrong with "packaging python".
And I guess the absence of an agreement on "app vs project vs site" is one of the roots of the problem.