Patchwork [2,of,4,website] base: add a requirements.txt

login
register
mail settings
Submitter Kevin Bullock
Date May 10, 2017, 5:22 p.m.
Message ID <b99251cd874a4a559cea.1494436943@ingalls.local>
Download mbox | patch
Permalink /patch/20559/
State Accepted
Headers show

Comments

Kevin Bullock - May 10, 2017, 5:22 p.m.
# HG changeset patch
# User Kevin Bullock <kbullock+mercurial@ringworld.org>
# Date 1494433855 18000
#      Wed May 10 11:30:55 2017 -0500
# Node ID b99251cd874a4a559ceadbd6fd33e6f411b1e776
# Parent  3faffcf56082846bd385f6594d9729bceceaf83b
base: add a requirements.txt
Gregory Szorc - May 11, 2017, 12:16 a.m.
On Wed, May 10, 2017 at 10:22 AM, Kevin Bullock <
kbullock+mercurial@ringworld.org> wrote:

> # HG changeset patch
> # User Kevin Bullock <kbullock+mercurial@ringworld.org>
> # Date 1494433855 18000
> #      Wed May 10 11:30:55 2017 -0500
> # Node ID b99251cd874a4a559ceadbd6fd33e6f411b1e776
> # Parent  3faffcf56082846bd385f6594d9729bceceaf83b
> base: add a requirements.txt
>
> diff --git a/requirements.txt b/requirements.txt
> new file mode 100644
> --- /dev/null
> +++ b/requirements.txt
> @@ -0,0 +1,1 @@
> +Flask>=0.12.1,<0.13
>

Modern versions of pip support pinning hashes in requirements files. It is
quite nice as it not only buffers you against MitM attacks, compromised
servers, and corruption, but also forces you to have hashes pinned for
*all* dependencies. In effect, it requires you to list *all* dependencies
and gives you peace of mind that your virtualenv is reproducible. I'd
highly recommend implementing that as a follow-up to this series and using
that practice in any other production pip requirements files you maintain.
Gregory Szorc - May 11, 2017, 3:19 a.m.
On Wed, May 10, 2017 at 7:55 PM, Kevin Bullock <
kbullock+mercurial@ringworld.org> wrote:

> > On May 10, 2017, at 19:16, Gregory Szorc <gregory.szorc@gmail.com>
> wrote:
> >
> >> On Wed, May 10, 2017 at 10:22 AM, Kevin Bullock <
> kbullock+mercurial@ringworld.org> wrote:
> >> # HG changeset patch
> >> # User Kevin Bullock <kbullock+mercurial@ringworld.org>
> >> # Date 1494433855 18000
> >> #      Wed May 10 11:30:55 2017 -0500
> >> # Node ID b99251cd874a4a559ceadbd6fd33e6f411b1e776
> >> # Parent  3faffcf56082846bd385f6594d9729bceceaf83b
> >> base: add a requirements.txt
> >>
> >> diff --git a/requirements.txt b/requirements.txt
> >> new file mode 100644
> >> --- /dev/null
> >> +++ b/requirements.txt
> >> @@ -0,0 +1,1 @@
> >> +Flask>=0.12.1,<0.13
> >>
> > Modern versions of pip support pinning hashes in requirements files. It
> is quite nice as it not only buffers you against MitM attacks, compromised
> servers, and corruption, but also forces you to have hashes pinned for
> *all* dependencies. In effect, it requires you to list *all* dependencies
> and gives you peace of mind that your virtualenv is reproducible. I'd
> highly recommend implementing that as a follow-up to this series and using
> that practice in any other production pip requirements files you maintain.
>
> Does anyone in the Python world put that sort of thing in a separate file?
> It seems perfectly reasonable to do something like:
>
>     $ pip install -r requirements.txt
>     $ pip freeze -r requirements.txt > requirements.frozen
>
> and then to install the precise hash-pinned versions somewhere else:
>
>     $ pip install -r requirements.frozen
>
> In fact this is precisely equivalent to what Bundler (for Ruby) and Yarn
> (for Node.js) do. I'd much rather have one file that declares the
> dependencies, and a _separate_ one that locks down the precise versions of
> those and all transitive dependencies.
>

The Python Packaging Guide seems to suggest that dependencies should be
declared with install_requires in setup.py and full environments should be
declared with pip requirements files.
https://packaging.python.org/requirements/#install-requires-vs-requirements-files

I've heard of people parsing files (possibly requirements files) in
setup.py in order to populate install_requires to avoid the duplication.
Sean Farley - May 12, 2017, 8:20 p.m.
Gregory Szorc <gregory.szorc@gmail.com> writes:

> On Wed, May 10, 2017 at 7:55 PM, Kevin Bullock <
> kbullock+mercurial@ringworld.org> wrote:
>
>> > On May 10, 2017, at 19:16, Gregory Szorc <gregory.szorc@gmail.com>
>> wrote:
>> >
>> >> On Wed, May 10, 2017 at 10:22 AM, Kevin Bullock <
>> kbullock+mercurial@ringworld.org> wrote:
>> >> # HG changeset patch
>> >> # User Kevin Bullock <kbullock+mercurial@ringworld.org>
>> >> # Date 1494433855 18000
>> >> #      Wed May 10 11:30:55 2017 -0500
>> >> # Node ID b99251cd874a4a559ceadbd6fd33e6f411b1e776
>> >> # Parent  3faffcf56082846bd385f6594d9729bceceaf83b
>> >> base: add a requirements.txt
>> >>
>> >> diff --git a/requirements.txt b/requirements.txt
>> >> new file mode 100644
>> >> --- /dev/null
>> >> +++ b/requirements.txt
>> >> @@ -0,0 +1,1 @@
>> >> +Flask>=0.12.1,<0.13
>> >>
>> > Modern versions of pip support pinning hashes in requirements files. It
>> is quite nice as it not only buffers you against MitM attacks, compromised
>> servers, and corruption, but also forces you to have hashes pinned for
>> *all* dependencies. In effect, it requires you to list *all* dependencies
>> and gives you peace of mind that your virtualenv is reproducible. I'd
>> highly recommend implementing that as a follow-up to this series and using
>> that practice in any other production pip requirements files you maintain.
>>
>> Does anyone in the Python world put that sort of thing in a separate file?
>> It seems perfectly reasonable to do something like:
>>
>>     $ pip install -r requirements.txt
>>     $ pip freeze -r requirements.txt > requirements.frozen
>>
>> and then to install the precise hash-pinned versions somewhere else:
>>
>>     $ pip install -r requirements.frozen
>>
>> In fact this is precisely equivalent to what Bundler (for Ruby) and Yarn
>> (for Node.js) do. I'd much rather have one file that declares the
>> dependencies, and a _separate_ one that locks down the precise versions of
>> those and all transitive dependencies.
>>
>
> The Python Packaging Guide seems to suggest that dependencies should be
> declared with install_requires in setup.py and full environments should be
> declared with pip requirements files.
> https://packaging.python.org/requirements/#install-requires-vs-requirements-files
>
> I've heard of people parsing files (possibly requirements files) in
> setup.py in order to populate install_requires to avoid the duplication.

Personally, I would avoid doing this until we really need it. :shrug:
Simon King - May 31, 2017, 8:45 a.m.
On Fri, May 12, 2017 at 9:20 PM, Sean Farley <sean@farley.io> wrote:
> Gregory Szorc <gregory.szorc@gmail.com> writes:
>
>> On Wed, May 10, 2017 at 7:55 PM, Kevin Bullock <
>> kbullock+mercurial@ringworld.org> wrote:
>>
>>> > On May 10, 2017, at 19:16, Gregory Szorc <gregory.szorc@gmail.com>
>>> wrote:
>>> >
>>> >> On Wed, May 10, 2017 at 10:22 AM, Kevin Bullock <
>>> kbullock+mercurial@ringworld.org> wrote:
>>> >> # HG changeset patch
>>> >> # User Kevin Bullock <kbullock+mercurial@ringworld.org>
>>> >> # Date 1494433855 18000
>>> >> #      Wed May 10 11:30:55 2017 -0500
>>> >> # Node ID b99251cd874a4a559ceadbd6fd33e6f411b1e776
>>> >> # Parent  3faffcf56082846bd385f6594d9729bceceaf83b
>>> >> base: add a requirements.txt
>>> >>
>>> >> diff --git a/requirements.txt b/requirements.txt
>>> >> new file mode 100644
>>> >> --- /dev/null
>>> >> +++ b/requirements.txt
>>> >> @@ -0,0 +1,1 @@
>>> >> +Flask>=0.12.1,<0.13
>>> >>
>>> > Modern versions of pip support pinning hashes in requirements files. It
>>> is quite nice as it not only buffers you against MitM attacks, compromised
>>> servers, and corruption, but also forces you to have hashes pinned for
>>> *all* dependencies. In effect, it requires you to list *all* dependencies
>>> and gives you peace of mind that your virtualenv is reproducible. I'd
>>> highly recommend implementing that as a follow-up to this series and using
>>> that practice in any other production pip requirements files you maintain.
>>>
>>> Does anyone in the Python world put that sort of thing in a separate file?
>>> It seems perfectly reasonable to do something like:
>>>
>>>     $ pip install -r requirements.txt
>>>     $ pip freeze -r requirements.txt > requirements.frozen
>>>
>>> and then to install the precise hash-pinned versions somewhere else:
>>>
>>>     $ pip install -r requirements.frozen
>>>
>>> In fact this is precisely equivalent to what Bundler (for Ruby) and Yarn
>>> (for Node.js) do. I'd much rather have one file that declares the
>>> dependencies, and a _separate_ one that locks down the precise versions of
>>> those and all transitive dependencies.
>>>
>>
>> The Python Packaging Guide seems to suggest that dependencies should be
>> declared with install_requires in setup.py and full environments should be
>> declared with pip requirements files.
>> https://packaging.python.org/requirements/#install-requires-vs-requirements-files
>>
>> I've heard of people parsing files (possibly requirements files) in
>> setup.py in order to populate install_requires to avoid the duplication.
>
> Personally, I would avoid doing this until we really need it. :shrug:
>

For what it's worth, pip-tools (https://github.com/jazzband/pip-tools)
helps with this. It can generate requirements.txt either from
install_requires in setup.py or a "requirements.in" file.

There's also pipfile (https://github.com/pypa/pipfile) which looks a
bit like the node.js system but is still in early development.

Simon

Patch

diff --git a/requirements.txt b/requirements.txt
new file mode 100644
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,1 @@ 
+Flask>=0.12.1,<0.13