On Fri, May 12, 2017 at 9:20 PM, Sean Farley <s...@farley.io> wrote: > Gregory Szorc <gregory.sz...@gmail.com> writes: > >> On Wed, May 10, 2017 at 7:55 PM, Kevin Bullock < >> kbullock+mercur...@ringworld.org> wrote: >> >>> > On May 10, 2017, at 19:16, Gregory Szorc <gregory.sz...@gmail.com> >>> wrote: >>> > >>> >> On Wed, May 10, 2017 at 10:22 AM, Kevin Bullock < >>> kbullock+mercur...@ringworld.org> wrote: >>> >> # HG changeset patch >>> >> # User Kevin Bullock <kbullock+mercur...@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 _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel