* Add .pre-commit-config.yaml to the project and exclude tests (for now). This does not include the MyPy linting that pip does but does include everything else.
- Remove bits about CC-BY-SA licensing
- Remove bits about using an embedded API key
- Add a little flair to the readme to acknowledge pyup
Signed-off-by: Dan Ryan <dan.ryan@canonical.com>
* Implements PEEP-006
* `pipenv lock -r --dev` is now consistent with other commands
and the CLI help output, and includes both default and dev
dependencies in the result
* New `--dev-only` option allows requesting the previous behaviour
(which was specifically designed to support the traditional
`requirements.txt`/`dev-requirements.txt` split)
The canonical Pipenv documentation is now at pipenv.pypa.io.
Also, the canonical GitHub repositories for Pipenv and
Requests have changed, and some other communications links
(Twitter, mailing list, "thank you") were no longer
operational. This commit updates those and clarifies that
Pipenv is a project maintained by the PyPA.
Fixes#4137.
Signed-off-by: Sumana Harihareswara <sh@changeset.nyc>
Clarify that `--deploy` is meant for enforcement and intentionally
failing a build.
Mention `pipenv sync` in the same section to try to establish it more
clearly as the most obvious and normal way of doing installation from
``Pipfile.lock`` as part of a reproducible build process.
Explicitly recommend against `pipenv install --ignore-pipfile` and
suggest that it may be deprecated.
Despite an application's Docker container not usually running other Python processes than the application itself, it still has a system Python whose packages should not necessarily be overwritten or upgraded by an application's choices.
For example, `python3-software-properties` in Ubuntu contains utilities
written in Python like `add-apt-repository` whose [use is widespread in
Dockerfiles](https://github.com/search?l=Dockerfile&q=%22add-apt-repository%22&type=Code).
By inadvertently applying an application's dependency onto the the container's Python, it is possible to:
- subtly break system-level software like these that is still present in the container image
- run into errors where that software is executed while extending the image with another Dockerfile
- run into errors when `docker run|exec ... COMMAND` is used to run another process inside the same container for debugging purposes
I realize this is not necessarily a likely use case, but we have seen
enough projects/tools vendoring `Requests` in fear of a conflict.
Very open on the wording and whether `system Python` is the correct term
to designate the global Python for that OS/container image.
Adds support for the --pypi-mirror command line parameter and the
PIPENV_PYPI_MIRROR environment variable for most pipenv operations.
This permits pipenv to function without pypi.org, which is necessary for
users:
1. behind restrictive networks
2. facing strict artifact sourcing policies
3. experiencing poor performance connecting to pypi.org
4. who've configured a local cache for performance reasons
When specified, the value of this parameter replaces all instances of
pypi.org and pypi.python.org within pipenv operations without modifying
or requring the modification of Pipfiles.
- Resolves#2075
Matt Davis