How to specify different version requirements of a package for multiple platforms?
(I promise I searched StackOverflow and google and failed to find an example of what I need.)
I have a normal looking Pipfile with one requirement like so:
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[packages]
ujson = "*"
[requires]
python_version = "2.7"
I wanted to pin ujson on Windows only to version 1.35 but use the latest on Linux.
Syntactically, is that even possible? I tried this but pipenv didn't likey:
[packages]
ujson = {version = "*",sys_platform = "!= 'win32'"}
ujson = {version = "==1.35",sys_platform = "== 'win32'"}
It doesn't want me to declare a package twice, so how would I join my marker conditionals? Can it be done?
$ pipenv --support
Pipenv version: '2020.4.1b1'
Pipenv location: '/home/alan/.local/lib/python2.7/site-packages/pipenv'
Python location: '/usr/bin/python2'
Python installations found:
3.6.9:/usr/bin/python3.63.6.9:/usr/bin/python3.6m3.6.9:/usr/bin/python33.5.2:/usr/bin/python3.53.5.2:/usr/bin/python3.5m2.7.17:/usr/bin/python2.72.7.17:/usr/bin/python2
PEP 508 Information:
{'implementation_name': 'cpython',
'implementation_version': '0',
'os_name': 'posix',
'platform_machine': 'x86_64',
'platform_python_implementation': 'CPython',
'platform_release': '4.15.0-99-generic',
'platform_system': 'Linux',
'platform_version': '#100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020',
'python_full_version': '2.7.17',
'python_version': '2.7',
'sys_platform': 'linux2'}
System environment variables:
_GOPATHPIP_PYTHON_PATHQT_QPA_PLATFORMTHEMEPIP_SHIMS_BASE_MODULEQT4_IM_MODULEGOROOTGOBINWINDOWPATHXDG_CURRENT_DESKTOPXDG_SESSION_TYPEQT_IM_MODULELOGNAMEUSERPATHXDG_VTNRHOMEDISPLAYSSH_AGENT_PIDLANGTERMSHELLXAUTHORITYLANGUAGESESSION_MANAGERXDG_DATA_DIRSMANDATORY_PATHQT_ACCESSIBILITYDRONE_TOKENPYLINTHOMECLUTTER_IM_MODULETEXTDOMAINGNOME_TERMINAL_SERVICEEDITORXMODIFIERSGOARCHGPG_AGENT_INFOGJS_DEBUG_OUTPUTDISTROGTK2_MODULESXDG_SESSION_DESKTOPXDG_RUNTIME_DIRGTK_IM_MODULEPYTHONPATHSSH_AUTH_SOCKDRONE_SERVERVTE_VERSIONUSERNAMEIM_CONFIG_PHASETEXTDOMAINDIRGNOME_SHELL_SESSION_MODEPYTHONDONTWRITEBYTECODEXDG_CONFIG_DIRSGOOSLESSOPENXDG_SESSION_IDDBUS_SESSION_BUS_ADDRESSNUKE_PATHGTK_MODULESGDMSESSIONDESKTOP_SESSIONLESSCLOSEDEFAULTS_PATHXDG_SEATPIP_DISABLE_PIP_VERSION_CHECKSHLVLPWDPYTHONFINDER_IGNORE_UNSUPPORTEDCOLORTERMXDG_MENU_PREFIXGNOME_DESKTOP_SESSION_IDLS_COLORSGJS_DEBUG_TOPICSGNOME_TERMINAL_SCREEN
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH:/home/alan/go/bin:/home/alan/google-cloud-sdk/bin:/home/alan/.poetry/bin:/home/alan/.local/bin:/home/alan/bin:/home/alan/.poetry/bin:/home/alan/bin:/home/alan/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/binSHELL:/bin/bashEDITOR:codeLANG:en_CA.UTF-8PWD:/home/alan
I found this article which is almost what I need:
https://dev.to/tomoyukiaota/creating-a-pipfile-which-has-different-installation-instructions-depending-on-operating-systems-pytorch-v041-as-an-example-56i8
... but it's not clear how I can get around the package name being the same when not having a url of the wheel (which I don't in my case.)
I ran into the following issue, here's what I've found @darkvertex Seems to work for now.
I ran into the following issue, here's what I've found @darkvertex Seems to work for now.
That article suggests:
[packages]
pymssql-win= {path = "./install/pymssql-2.1.4-cp36-cp36m-win_amd64.whl", os_name = "=='nt'"}
pymssql = {version = "*", os_name = "=='posix'"}
...but this only works because the keys are different between the two lines, and the name doesn't matter for the one installing from a .whl file because it's using a file.
That's a quasi-valid workaround but it means for one OS I cannot use pipenv's own version resolver since I would need to embed the url to the .whl
What I would prefer, if it were possible, would be some syntax like:
[packages]
ujson = {version = "*",sys_platform = "!= 'win32'"}
ujson-windows = {name = "ujson", version = "==1.35",sys_platform = "== 'win32'"}
...but AFAIK overriding the package name is not allowed.
Since removing requirementslib dependency, it would actually be relatively straight forward to add a name override now.