Merge branch 'master' into bugfix/4286

This commit is contained in:
Dan Ryan
2020-05-29 02:25:22 -04:00
committed by GitHub
8 changed files with 41 additions and 7 deletions
View File
+23 -4
View File
@@ -31,6 +31,15 @@ You can begin by reviewing vendored dependencies which can be found in `pipenv/v
Next you can consult `pipenv/patched/patched.txt` which enumerates the patched dependencies. Follow the same process, but be aware that you will need to rewrite patches for each dependency once you update (most likely) as they do tend to change somewhat substantially.
### Update Safety
Pipenv also includes a vendored copy of `safety` for checking for vulnerabilities against the `pyup.io` database. In order to update the `safety` package, run the following:
```console
$ inv vendoring.update-safety
```
### Updating patches
For larger libraries you can keep local clones of them and simply generate full patch sets in which you replace the updated path in pipenv when you are done making changes. Here is an example of a script used from inside a local clone of `pip` to generate a patch and copy it to pipenv's local patches directory.
@@ -74,12 +83,18 @@ $ pipenv run inv vendoring.update
This will automatically remove the `./pipenv/vendor/` and `./pipenv/patched/` directories and re-download and patch the specified dependencies. It will also attempt to download any relevant licenses. Once this is completed, run `git status` and inspect the output -- look through the `git diff` for anything that may cause breakages. If any licenses have been deleted, you will need to determine why they were not replaced by the license download tooling.
## Review Vendored Licenses
Make sure to read through any modified license files for changes -- note that we cannot redistribute code that is licensed under a [copyleft](https://en.wikipedia.org/wiki/Copyleft) license, such as the [GPL](https://en.wikipedia.org/wiki/GPL). Similarly, all vendored code **must** be licensed or it cannot be redistributed. If vendored libraries have become unlicensed or are no longer usable, suitable replacements will have to be found and potentially patched into the vendored dependencies. This may be a good time to consider simply including the dependency as an install requirement.
### TODO
Look into using a tool like https://fossa.com/ to help with this.
## Update Pipfile.lock
Now we will need to update the lockfile. You will need to run the following:
Now we will need to update the lockfile. This is required to ensure tests run against the latest versions of libraries. You will need to run the following:
```bash
# use the latest python here
@@ -144,10 +159,14 @@ If in doubt, follow the basic instructions below.
3. Get credentials to co-maintain the pipenv project on PyPI.org -- **SPOF alert**
4. Set the version number to [a pre-release identifier](https://www.python.org/dev/peps/pep-0440/#pre-release-separators)
5. Package and upload pipenv [to PyPI](https://pypi.org/project/pipenv/#history) as a pre-release/alpha
6. Publicize on distutils-sig, pypa-dev, and the relevant GitHub issue(s)
7. Wait a week, then update version number to a canonical release and re-release on PyPI.org
6. Publicize on distutils-sig, [Discourse](https://discuss.python.org/c/packaging), and the relevant GitHub issue(s)
a. write up diplomatic notification
7. Recruit manual testing ([example](https://pad.sfconservancy.org/p/help-test-pipenv-2020-03-26)) for workflows we don't account for
8. Wait a week, then update version number to a canonical release and re-release on PyPI.org
10. Publicize on lists, Discourse, GitHub issues
## Looking ahead
Most of the pipenv related ecosystem libraries are using [github actions](https://github.com/sarugaku/vistir/blob/master/.github/workflows/pypi_upload.yml) to automate releases when tags are pushed. Most likely we will look to move in this direction and simplify the process.
Most of the pipenv related ecosystem libraries are using [GitHub actions](https://github.com/sarugaku/vistir/blob/master/.github/workflows/pypi_upload.yml) to automate releases when tags are pushed. Most likely we will look to move in this direction and simplify the process.
+1
View File
@@ -0,0 +1 @@
Fix a bug that caused non-specific versions to be pinned in ``Pipfile.lock``.
+2
View File
@@ -0,0 +1,2 @@
Remove expection of ``version`` key in ``test_ssh_vcs_install`` to prevent it
from failing.
+1 -1
View File
@@ -2,4 +2,4 @@
# // ) ) / / // ) ) //___) ) // ) ) || / /
# //___/ / / / //___/ / // // / / || / /
# // / / // ((____ // / / ||/ /
__version__ = "2020.5.28"
__version__ = "2020.5.28.dev0"
+1 -1
View File
@@ -1191,7 +1191,7 @@ def get_locked_dep(dep, pipfile_section, prefer_pipfile=True):
lockfile_name, lockfile_dict = lockfile_entry.copy().popitem()
lockfile_version = lockfile_dict.get("version", "")
# Keep pins from the lockfile
if prefer_pipfile and lockfile_version != version and version.startswith("=="):
if prefer_pipfile and lockfile_version != version and version.startswith("==") and "*" not in version:
lockfile_dict["version"] = version
lockfile_entry[lockfile_name] = lockfile_dict
return lockfile_entry
-1
View File
@@ -59,7 +59,6 @@ def test_ssh_vcs_install(PipenvInstance):
assert p.lockfile["default"]["six"] == {
"git": "ssh://git@github.com/benjaminp/six.git",
"ref": "15e31431af97e5e64b80af0a3f598d382bcdd49a",
"version": "==1.11.0"
}
+13
View File
@@ -748,3 +748,16 @@ def test_lock_nested_vcs_direct_url(PipenvInstance):
assert "git" in p.lockfile["default"]["sibling-package"]
assert "subdirectory" in p.lockfile["default"]["sibling-package"]
assert "version" not in p.lockfile["default"]["sibling-package"]
@pytest.mark.lock
@pytest.mark.install
def test_lock_package_with_wildcard_version(PipenvInstance):
with PipenvInstance(chdir=True) as p:
c = p.pipenv("install 'six==1.11.*'")
assert c.ok
assert "six" in p.pipfile["packages"]
assert p.pipfile["packages"]["six"] == "==1.11.*"
assert "six" in p.lockfile["default"]
assert "version" in p.lockfile["default"]["six"]
assert p.lockfile["default"]["six"]["version"] == "==1.11.0"