Using pysqlite3-binary fails on install --deploy when locked on M1 and installed on Linux
#5723
Comments
nk9
changed the title
|
I think the problem here is that I'm developing on an M1 Mac but deploying on a Linux container. Since the Mac ignores the I have worked around this by locking within Docker like so: -COPY Pipfile* ./
+COPY Pipfile ./
-RUN PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy --verbose
+RUN PIPENV_VENV_IN_PROJECT=1 pipenv install --verboseHowever, this goes against the pipenv recommendtion to avoid modifying the lockfile during CI. So I would prefer another solution. I also tried this approach of locking in the CI using RUN PIPENV_VENV_IN_PROJECT=1 pipenv lock --keep-outdated
RUN PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy --verboseBut I got the same failure as before for some reason. Lastly, I tried using packages categories to restrict the locking to just the sqlite package, like so: [packages]
requests = "*"
boto3 = "*"
jinja2 = "*"
pytz = "*"
[sqlite]
pysqlite3-binary = { version = "*", platform_machine = "== 'x86_64'" }
[dev-packages]
isort = "*"
black = "*"
flake8 = "*"I then lock just that category in the Dockerfile: COPY Pipfile* ./
RUN PIPENV_VENV_IN_PROJECT=1 pipenv lock --categories sqlite
RUN PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy --categories="packages sqlite" --verboseThis works, and seems like the least bad option. But please let me know if I'm missing something. |
Yeah, this is probably your least bad option for now. The fundamental problem of building an sdist and getting the hashes for a different system than the one you are locking on is a well known problem. |
nk9
changed the title
install --deploy when locked on M1 and installed on Linux
|
Alright, thanks for confirming. Would be great to get a cleaner solution, but I'll use the multiple categories for now. |
Issue description
I have a Pipfile which has two requirements in it,
pysqlite3-binaryandpytz. Either requirement installs successfully on its own, but pipenv fails when asked to install them together. In testing, I've discovered that it appears that ANY package paired withpysqlite3-binarywill cause the install to fail.Expected result
I expected the install to work. This same setup worked last year, but when I tried to do it again, it failed this time.
Actual result
Build log
Steps to replicate
Provide the steps to replicate (which usually at least includes the commands and the Pipfile).
Take this Dockerfile:
And this Pipfile:
And then attempt to build the Dockerfile:
NB: the
pysqlite3-binarypackage only has Linux wheels, hence the platform specifics. Also, I have tried bothversion = "*"and pinning the version to0.5.0, but get the same failure each time.I'm on an M1 Mac, although this same error is happening on GitHub Actions when it tries to build the container there.
$ pipenv --support
Pipenv version:
'2023.6.2'Pipenv location:
'/var/lang/lib/python3.10/site-packages/pipenv'Python location:
'/var/lang/bin/python3.10'OS Name:
'posix'User pip version:
'23.1.2'user Python installations found:
PEP 508 Information:
System environment variables:
_HOMESHLVLPYTHONDONTWRITEBYTECODETZLAMBDA_RUNTIME_DIRLANGPYTHONFAULTHANDLERPWDPATHLAMBDA_TASK_ROOTLD_LIBRARY_PATHLC_ALLPIP_DISABLE_PIP_VERSION_CHECKPIP_PYTHON_PATHPYTHONFINDER_IGNORE_UNSUPPORTEDPipenv–specific environment variables:
Debug–specific environment variables:
PATH:/var/lang/bin:/usr/local/bin:/usr/bin/:/bin:/opt/binLANG:C.UTF-8PWD:/var/taskContents of
Pipfile('/var/task/Pipfile'):Contents of
Pipfile.lock('/var/task/Pipfile.lock'):{ "_meta": { "hash": { "sha256": "2b1a32fdca8e7cac9c7b8bc7db8cd7219f6ff51cd0ed4002293e5ff66d36200f" }, "pipfile-spec": 6, "requires": { "python_version": "3.10" }, "sources": [ { "name": "pypi", "url": "https://pypi.org/simple", "verify_ssl": true } ] }, "default": { "pysqlite3-binary": { "platform_machine": "== 'x86_64'", "version": "*" }, "pytz": { "hashes": [ "sha256:1d8ce29db189191fb55338ee6d0387d82ab59f3d00eac103412d64e0ebd0c588", "sha256:a151b3abb88eda1d4e34a9814df37de2a80e301e68ba0fd856fb9b46bfbbbffb" ], "index": "pypi", "version": "==2023.3" } }, "develop": {} }The text was updated successfully, but these errors were encountered: