Lib vs ( App | Project | ... )
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. What do you think? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
On 17 May 2016 at 21:09, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
Am 17.05.2016 um 15:20 schrieb Nick Coghlan:
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.
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, ....
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-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? 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/
On Tue, May 17, 2016 at 11:38 PM, Thomas Güttler < guettliml@thomas-guettler.de> wrote:
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....
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.
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 :-)
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 Wed, May 18, 2016, 01:39 Thomas Güttler <guettliml@thomas-guettler.de> wrote:
That's a rather negative statement to make. Someone took the time to write that glossary entry and their work should be appreciated, even if you disagree with whether it met your expectations for a definition. If you would like to clarify it then feel free to submit a PR to change it.
On 18 May 2016 at 16:38, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
`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.
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?").
Yes, Django is a project.
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 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).
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
Thomas Güttler writes:
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
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
Am 20.05.2016 um 13:36 schrieb Steven D'Aprano:
There is no actual problem. There is not uncaught exception and 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. Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
"how to call the container for the libraries, the one thing providing the environment?" In Visual Studio we call these Environments (in the source they're still referred to as Interpreters). A "virtual environment" is just a specific type of environment (one that inherits a stdlib and/or packages), as is an isolated environment (hosted in an app, or a conda env). They all specify a Python version and concrete versions of libraries - something directly executable, not something that needs to be actualised before use. 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 -----Original Message----- From: "Thomas Güttler" <guettliml@thomas-guettler.de> Sent: 5/17/2016 4:28 To: "python-ideas" <python-ideas@python.org> Subject: [Python-ideas] Lib vs ( App | Project | ... ) 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. What do you think? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
On 17 May 2016 at 21:09, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
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 | ncoghlan@gmail.com | Brisbane, Australia
Am 17.05.2016 um 15:20 schrieb Nick Coghlan:
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.
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, ....
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-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? 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/
On Tue, May 17, 2016 at 11:38 PM, Thomas Güttler < guettliml@thomas-guettler.de> wrote:
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....
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.
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 :-)
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 Wed, May 18, 2016, 01:39 Thomas Güttler <guettliml@thomas-guettler.de> wrote:
That's a rather negative statement to make. Someone took the time to write that glossary entry and their work should be appreciated, even if you disagree with whether it met your expectations for a definition. If you would like to clarify it then feel free to submit a PR to change it.
On 18 May 2016 at 16:38, Thomas Güttler <guettliml@thomas-guettler.de> wrote:
`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.
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?").
Yes, Django is a project.
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 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).
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
Thomas Güttler writes:
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
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
Am 20.05.2016 um 13:36 schrieb Steven D'Aprano:
There is no actual problem. There is not uncaught exception and 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. Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/
"how to call the container for the libraries, the one thing providing the environment?" In Visual Studio we call these Environments (in the source they're still referred to as Interpreters). A "virtual environment" is just a specific type of environment (one that inherits a stdlib and/or packages), as is an isolated environment (hosted in an app, or a conda env). They all specify a Python version and concrete versions of libraries - something directly executable, not something that needs to be actualised before use. 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 -----Original Message----- From: "Thomas Güttler" <guettliml@thomas-guettler.de> Sent: 5/17/2016 4:28 To: "python-ideas" <python-ideas@python.org> Subject: [Python-ideas] Lib vs ( App | Project | ... ) 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. What do you think? Regards, Thomas Güttler -- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (7)
-
Brett Cannon -
Chris Barker -
Nick Coghlan -
Stephen J. Turnbull -
Steve Dower -
Steven D'Aprano -
Thomas Güttler