| 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
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.
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.
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:
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