-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Can't lock requirements if platform does not match #5842
Comments
With the --skip-lock being removed, this is kind of a big deal. Is there a way to choose the lock file to use? Maybe users could ship platform specific lock files if pipenv will not build cross-platform lock files? May be related to #5561 e.g. $ pipenv install --lock Pipfile-nt.lock
$ pipenv install --lock Pipfile-nix.lock Moreover, the recommended workaround doesn't work without a Pipfile.lock file. |
I want to comment on this that it is a high priority issue -- while I am not oppose to considering platform specific lock files, that will be significant work -- while it was useful to remove |
As a secondary issue -- the |
I've done some light testing/iterating on a branch that seems to get We can have further discussions around how to move forward with the platform locking limitations aside from that. |
Honestly still have no idea how requirementslib was picking a version to use for this and then the resolve hash step for at least that top level dependency would "work". However what I do now I just transfer the specifier from the Pipfile over to the lockfile, which isn't really correct in all case. |
I am working on a path forward for cross platform dependencies, and I think I have something that might stick. #5892 Its probably only consider sys_platform markers right now, but I think it makes sense to apply it to all marker types. Please have a look ... here is an example:
` |
@n1ngu Following up on my message from this morning, I've extended my branch to include also a top level platform_machine. Using a modified version of your Pipfile and my branch:
|
|
Issue description
So far we have been listing
in Pipfiles so that Linux and Mac developers could both benefit from reproducible installs of a project via pipenv.
Expected result
This worked fine, both packages were locked on the same version (most usually) and depending on who issued a pipenv install either one would be actually installed.
Actual result
As of pipenv 2023.08.20 trying to lock on a Linux box will produce a very strange lock file listing psycopg2 on version "*" (what?) with no hashes.
Output for
pipenv lock --verbose
:Steps to replicate
Try to run
pipenv lock
on a Linux box$ pipenv --support
Pipenv version:
'2023.8.20'
Pipenv location:
'/usr/local/lib/python3.11/site-packages/pipenv'
Python location:
'/usr/local/bin/python'
OS Name:
'posix'
User pip version:
'23.2.1'
user Python installations found:
PEP 508 Information:
System environment variables:
PYTHONDEVMODE
PIPENV_VENV_IN_PROJECT
CELERY_BROKER_URL
HOSTNAME
PYTHON_VERSION
DJANGO_EMAIL_HOST
DJANGO_SECRET_KEY
PWD
DJANGO_SENTRY_ENVIRONMENT
DB_ENGINE
DJANGO_EMAIL_PORT
PYTHON_SETUPTOOLS_VERSION
DB_PORT
DB_USER
HOME
LANG
DJANGO_SENTRY_DSN
GPG_KEY
DJANGO_ALLOWED_HOSTS
DJANGO_EMAIL_HOST_PASSWORD
DJANGO_SETTINGS_MODULE
DJANGO_MEDIA_ROOT
TERM
DB_HOST
DB_PASSWD
DJANGO_DEBUG
SHLVL
DJANGO_EMAIL_HOST_USER
PYTHON_PIP_VERSION
DB_NAME
PYTHON_GET_PIP_SHA256
PYTHONBREAKPOINT
PYTHON_GET_PIP_URL
PATH
DJANGO_STATIC_ROOT
PIPENV_SHELL
OLDPWD
_
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PYTHONFINDER_IGNORE_UNSUPPORTED
Pipenv–specific environment variables:
PIPENV_VENV_IN_PROJECT
:1
PIPENV_SHELL
:bash
Debug–specific environment variables:
PATH
:/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG
:C.UTF-8
PWD
:/app/asdf
Contents of
Pipfile
('/app/asdf/Pipfile'):Contents of
Pipfile.lock
('/app/asdf/Pipfile.lock'):The text was updated successfully, but these errors were encountered: