Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

problem with canonicalized package names in Pipfile.lock #3011

Closed
freddrake opened this issue Oct 11, 2018 · 4 comments
Closed

problem with canonicalized package names in Pipfile.lock #3011

freddrake opened this issue Oct 11, 2018 · 4 comments

Comments

@freddrake
Copy link

I've been running pipenv 2018.05.18, but updated to 2018.10.09 today while investigating an issue a colleague reported. With a build that was working with the earlier version, the new version complained:

$ pipenv lock
Creating a virtualenv for this project…
Pipfile: /home/fdrake/p/fa/service/Pipfile
Using /home/fdrake/tools/pipenv/bin/python3 (3.6.6) to create virtualenv…
⠴Already using interpreter /home/fdrake/tools/pipenv/bin/python3
Using base prefix '/opt/kt-python36'
New python executable in /home/fdrake/.local/share/virtualenvs/service-MJi0PMYp/bin/python3
Also creating executable in /home/fdrake/.local/share/virtualenvs/service-MJi0PMYp/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /home/fdrake/.local/share/virtualenvs/service-MJi0PMYp
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (b2bd72)!
$ pipenv sync
Installing dependencies from Pipfile.lock (b2bd72)…
An error occurred while installing kt-testing==3.0.0! Will try again.
An error occurred while installing kt-testing==3.0.0 --hash=sha256:25ffb1b4b8f217de5ff09ffd99a885933e02830e2f8da44422f1aaa9fb86c22c! Will try again.
An error occurred while installing zc-lockfile==1.3.0! Will try again.
An error occurred while installing zc-lockfile==1.3.0 --hash=sha256:96cb13769e042988ea25d23d44cf09342ea0f887083d0f9736968f3617665853! Will try again.
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 49/49 — 00:00:27
Installing initially failed dependencies…
Looking in indexes: https://devpi.keepertech.com/keeper/prod/+simple/
Collecting kt-testing==3.0.0 

  Could not find a version that satisfies the requirement kt-testing==3.0.0 (from -r /tmp/pipenv-i7dq9akj-requirements/pipenv-3jhunifz-requirement.txt (line 1)) (from versions: )
No matching distribution found for kt-testing==3.0.0 (from -r /tmp/pipenv-i7dq9akj-requirements/pipenv-3jhunifz-requirement.txt (line 1))

  ☤  ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/4 — 00:00:00

Actual result

Running pipenv lock appeared to succeed (no reported errors), but pipenv sync could not locate one package (kt.testing, freely available on PyPI as an sdist).

Output from pipenv lock --verbose and pipenv sync --verbose attached, as are Pipfile and Pipfile.lock.

Downgrading pipenv to version 2018.05.18 makes this work again, but that's not a long-term solution.

It's interesting that the Pipfile.lock generated by 2018.10.09 includes two sections for packages that include a dot in their name, and they are not identical:

        "kt-common": {
            "hashes": [
                "sha256:a4790a9885468b8da8ad311e461d8c6c17f3e5d031d24a0a9d7c419861ae06b1"
            ],
            "version": "==1.6.0"
        },
        ...,
        "kt.common": {
            "hashes": [
                "sha256:a4790a9885468b8da8ad311e461d8c6c17f3e5d031d24a0a9d7c419861ae06b1",
                "sha256:bec87e9465873d1612f1e58fcdb71b80c628c40fd79be47abdeb232d218b5f57"
            ],
            "version": "==1.6.0"
        },

The difference appears to be that the canonicalized version does not include a hash for the sdist. The kt.testing (and anything else only published as an sdist), that means the canonicalized entry won't have any hashes:

        "kt-testing": {
            "hashes": [],
            "version": "==3.0.0"
        },
        ...,
        "kt.testing": {
            "hashes": [
                "sha256:25ffb1b4b8f217de5ff09ffd99a885933e02830e2f8da44422f1aaa9fb86c22c"
            ],
            "version": "==3.0.0"
        },

Pipenv version: '2018.10.9'

Pipenv location: '/home/fdrake/tools/pipenv/lib/python3.6/site-packages/pipenv'

Python location: '/home/fdrake/tools/pipenv/bin/python3'

Python installations found:

  • 3.5.2: /usr/bin/python3.5m
  • 3.5.2: /usr/bin/python3.5
  • 2.7.12: /usr/bin/python2.7

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.6.6',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.4.0-137-generic',
 'platform_system': 'Linux',
 'platform_version': '#163-Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018',
 'python_full_version': '3.6.6',
 'python_version': '3.6',
 'sys_platform': 'linux'}

System environment variables:

  • XDG_SESSION_ID
  • NVM_CD_FLAGS
  • TERM
  • SHELL
  • SSH_CLIENT
  • OLDPWD
  • SSH_TTY
  • NVM_DIR
  • USER
  • LS_COLORS
  • SSH_AUTH_SOCK
  • MAIL
  • PATH
  • LC_COLLATE
  • PWD
  • LANG
  • SHLVL
  • HOME
  • LOGNAME
  • XDG_DATA_DIRS
  • SSH_CONNECTION
  • NVM_BIN
  • LESSOPEN
  • XDG_RUNTIME_DIR
  • LESSCLOSE
  • _
  • PYTHONDONTWRITEBYTECODE
  • PIP_SHIMS_BASE_MODULE
  • PIP_PYTHON_PATH

Pipenv–specific environment variables:

Debug–specific environment variables:

  • PATH: /home/fdrake/bin:/home/fdrake/.local/bin:/home/fdrake/.nvm/versions/node/v6.10.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
  • SHELL: /bin/bash
  • LANG: en_US.UTF-8
  • PWD: /home/fdrake/p/fa/service
@freddrake
Copy link
Author

@freddrake
Copy link
Author

I will note that the various kt.* packages other than kt.testing are only available from an internal DevPI server.

@techalchemy
Copy link
Member

See #2956 as a jumping off point or try installing from master, this one is super annoying but I am pretty sure we sorted it out— pip install -e git+https://github.com/pypa/pipenv.git@master#egg=pipenv. Let me know if that resolves it— thanks!

@freddrake
Copy link
Author

Thanks, @techalchemy! Using master does make things better. I'll keep my colleague on the old version for now, and we'll move to the next release when it's ready if everything checks out then.

With master, I'm seeing only the given names of the packages in Pipfile.lock, which is easier to understand for the non-packaing-masochists among us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants