It's probably a good idea here to explicitly distinguish between the kind
of application that's a web app you deploy to sort of managed server
environment, and the kind of application that's a command line or GUI tool
that people download and run. The same word means radically different
things to different people :-). I believe Paul's advice below is
specifically addressing the former case, not the latter.
On Jan 13, 2017 5:07 AM, "Paul Moore" <p.f.mo...@gmail.com> wrote:
> On 13 January 2017 at 12:23, Thomas Güttler
> <guettl...@thomas-guettler.de> wrote:
> > Am 12.01.2017 um 13:43 schrieb Nick Coghlan:
> >>
> >> On 12 January 2017 at 22:04, Thomas Güttler
> >> <guettl...@thomas-guettler.de> wrote:
> >>>
> >>> I came across a python library which has docs, which start like this:
> >>>
> >>> {{{
> >>>
> >>> Quickstart
> >>>
> >>> Include foolib in your requirements.txt file.
> >>>
> >>> }}}
> >>>
> >>> AFAIK dependencies should be specified via `install_requires` in
> >>> `setup.py`.
> >>
> >>
> >> Applications and services don't necessarily have a setup.py file -
> >> setup.py is more for pip-installable libraries and frameworks (see
> >> https://caremad.io/posts/2013/07/setup-vs-requirement/ for more on
> >> that topic).
> >
> >
> > What is an application?
> >
> > The django project uses this definition:
> > https://docs.djangoproject.com/en/1.10/ref/applications/
> >
> > I guess you mean something else, if you talk about "application".
> >
> > What is an application for you?
>
> IMO, an "application" in this context is a standalone program
> (implemented in Python). This is as opposed to a "library" which is
> written to be imported in other Python code. Obviously, there's some
> overlap - some "applications" provide a "programming API" that can be
> imported, and some libraries provide command line entry points.
>
> A library (something that you import) should declare in its metadata
> that you need to have its dependencies installed before it will work.
> That lets you (the user of the library) be ignorant of the
> dependencies of the library (which are implementation details as far
> as you are concerned) - pip just sorts it out for you from the
> metadata. To get the dependency metadata, the *library* should include
> its dependencies in install_requires in its setup.py.
>
> For applications on the other hand, you need to install exactly the
> environment you tested, so you *don't* use dependency metadata.
> Rather, you create a requirements.txt file that contains the exact
> versions of everything (direct dependencies) your application needs,
> then deploy your application script to a Python environment where
> you've run "pip install -r requirements.txt" to set it up correctly.
>
> As I say, there are lots of grey areas here. But from your
> description, the library you found sounds like it should have
> dependency metadata, and not need you to use a requirements file. On
> the other hand, the "Quickstart" may be trying to tell people how to
> use foolib in their *application*, in which case it's correct. (It's
> oversimplified, as if you're writing a library that depends on foolib
> you'd use install_requires, but simply changing the text to just say
> "put foolib in your install_requires" is no better, as then you'd have
> ignored the application use case...)
>
> If you can point to the actual library you're referring to, it would
> be easier to be specific :-)
>
> Paul
> _______________________________________________
> Distutils-SIG maillist - Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
