Scott-freeze
Keep requirements.in with unpinned or loosely pinned requirements, and let scott freeze them into requirements.txt for tests and deployment:
$ cat requirements.in flask>0.9
$ scott-freeze requirements.in > requirements.txt
$ cat requirements.txt # Generated file. Please do not edit manually # # `requirements.in` contains direct dependencies (and may be >version instead # of ==version) This file is a list of dependencies and _their_ dependencies, # completely frozen. To generate this file, use scott-freeze # # Example # $ scott-freeze requirements.in > requirements.txt # Flask==0.10.1 itsdangerous==0.24 Jinja2==2.7.3 MarkupSafe==0.23 Werkzeug==0.9.6
Version control
We recommend that you keep both requirements.in and requirements.txt in your repo.
License
Apache 2.0. See LICENSE for details.
2 maintainers
Metadata
2 maintainers
Release files for scott-freeze 0.1
For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.
Source distribution (sdist)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| scott-freeze-0.1.tar.gz | 3.2 kB | Without provenance | Details |
Release files / scott-freeze-0.1.tar.gz
| Download URL | scott-freeze-0.1.tar.gz |
|---|---|
| Size | 3.2 kB |
| Tags | Source |
|
SHA-256 checksum How to use checksums |
5fda4d73ad325591d7d5aa9d628468fc513199938e9ccb6ce92c718df834ceb6
|
|
BLAKE2b-256 checksum How to use checksums |
4b8a81f9ed9ac14cab52508a5c86903bad3c593d2e526f8a1ceefd13eef6b99c
|
| Upload date | |
|
Uploaded using Trusted Publishing? What is trusted publishing? |
No |
Security for scott-freeze 0.1
Provenance
Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.
No provenance found
None of the files in this release were uploaded with provenance metadata.
A note on package security
PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.
