* Depend on requests and certifi from vendored pip and remove it as explicit vendor dependency.
* Documentation tweak.
* Add a news fragment.
* Update remaining vendor dependencies to point at the pip requests.
* vendoring task needs requests.
* Include markers
* Change to marker flag and include test
* Flip markers flag to exclude by default
* Docs and newsfile
* Let default dependencies update dev dependencies
* Improve documentation around index restrictions
* Update docs/advanced.rst
* Refine index documentation updates. Factor out and re-use method before closing down other PR.
* Fully remove the --extra-index-url argument
Co-authored-by: Yusuke Nishioka <yusuke.nishioka.0713@gmail.com>
* 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.
Matt Davis