pipenv does not pull in extras if extra name does not match module name #5944
Comments
|
We need the proper package name for pip resolve/install, that is why. |
|
ya but this works in pipenv |
|
It can be considered a regression, but its not one I intend to "fix" this since was dependent on requirementslib behavior which has since been removed. I don't think its unreasonable to derive the package name from the Pipfile entry -- trying to determine it otherwise from the package itself is an expensive and error prone operation especially considering the many forms of setup.py and the desire to not evaluate code from setup.py during package resolution. Open to patches, but I won't be pursuing a patch for this. |
I'm not sure what you mean by you need the proper package name. extras_require={
'datetime': ["pytz"],
'fakefactory': ["Faker>=0.7.0,<=0.7.1"],
'django': ['pytz', 'django>=1.8,<2,!=1.9.*'],
'numpy': ['numpy>=1.9.0'],
'pytest': ['pytest>=2.8.0'],
}if they instead put: and in the Pipfile we put: Remember we need to specify the alias because the alias can point to one pipenv would pull the requirement. This needs to get fixed otherwise we cannot rely on pipenv properly enforcing version requirements across top level modules, and extras. |
|
the original Pipfile is equivalent to |
|
Sorry if there was a misunderstanding, I thought you were saying the name of the requirement in the Pipfile did not match the requirement name. When I try your example the resolve prints out:
When I checked the wheel for hypothesis, we can see there is no extras group named datetime in the published wheel. It is named pytz there (I am not sure why). That is what the pypi resolution will use the wheel metadata to determine the extras, so I don't think that is a pipenv bug. When I try with the git repository, I have to manually manipulate the Pipfile entry to have the extras but that is working: The biggest issue I can see is that there should be a way to pipenv install the Pipfile entry with the extras for the git repository example without having to edit the Pipfile. However for the case of the wheels extras groups not matching the setup.py extras groups from 8 years ago -- probably has to do with a recently published wheel of the hypothesis project? |
|
ok perhaps I picked a bad example, we're seeing this same issue at work for our own module, let me make an example w/o pypi |
|
sorry, will close this until I get a test case that buttons down all the hatches :) |
Issue description
If a requirement has extras, with a name that does not match the module name the module will not get added to the lockfile
Note that the datetime extra should pull in pytz: https://github.com/bennylope/hypothesis-python/blob/master/setup.py#L41
Expected result
Extras specified should get added
Actual result
Steps to replicate
Provide the steps to replicate (which usually at least includes the commands and the Pipfile).
$ pipenv --support
Pipenv version:
'2023.9.8'Pipenv location:
'/opt/homebrew/lib/python3.11/site-packages/pipenv'Python location:
'/opt/homebrew/opt/[email protected]/bin/python3.11'OS Name:
'posix'User pip version:
'23.2.1'user Python installations found:
PEP 508 Information:
System environment variables:
SHELLNVM_RC_VERSIONXPC_FLAGSHISTCONTROLTERM_PROGRAM_VERSIONPKG_CONFIG_PATHHISTSIZE__CFBundleIdentifierSSH_AUTH_SOCKTERM_SESSION_IDGPG_TTYPWDLOGNAMELaunchInstanceIDHOMELANGSECURITYSESSIONIDTMPDIRFBNSECRETS_FORCE_USERNVM_DIRGEM_HOMETERMUSERSHLVLNVM_CD_FLAGSXPC_SERVICE_NAMEPS1PATHHOMEBREW_CASK_OPTSOLDPWDTERM_PROGRAM___CF_USER_TEXT_ENCODINGPIP_DISABLE_PIP_VERSION_CHECKPYTHONDONTWRITEBYTECODEPYTHONFINDER_IGNORE_UNSUPPORTEDPipenv–specific environment variables:
Debug–specific environment variables:
PATH:/Users/alexmohr/Downloads/google-cloud-sdk/bin:/opt/homebrew/opt/openjdk/bin:/Users/alexmohr/.gem/bin:/opt/homebrew/bin:/opt/homebrew/opt/[email protected]/bin:/opt/homebrew/opt/[email protected]/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin:/Library/Apple/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/homebrew/opt/openjdk/bin:~/.gem/ruby/2.6.0/bin:/Users/alexmohr/dev/fbn.com/ops/docker/ecr/bin:~/Applications/Sublime Text.app/Contents/SharedSupport/binSHELL:/opt/homebrew/bin/bashLANG:en_US.UTF-8PWD:/tmp/testContents of
Pipfile('/private/tmp/test/Pipfile'):Contents of
Pipfile.lock('/private/tmp/test/Pipfile.lock'):{ "_meta": { "hash": { "sha256": "f1eb1944c7bc948a5bc4e1d5dd0a8e75b99e6b43cad9d3a3c222e3f840a9a3bc" }, "pipfile-spec": 6, "requires": { "python_version": "3.11" }, "sources": [ { "name": "pip_conf_index_global", "url": "https://pypi.fbn.org/simple", "verify_ssl": false } ] }, "default": { "attrs": { "hashes": [ "sha256:1f28b4522cdc2fb4256ac1a020c78acf9cba2c6b461ccd2c126f3aa8e8335d04", "sha256:6279836d581513a26f1bf235f9acd333bc9115683f14f7e8fae46c98fc50e015" ], "markers": "python_version >= '3.7'", "version": "==23.1.0" }, "hypothesis": { "extras": [ "datetime" ], "hashes": [ "sha256:e1d36522824d62bb3e9fcb7b57dd4a6ca330bb36921324bb19c476bdafabeda7", "sha256:e5d75d70f5a4fc372cddf03ec6141237a0a270ed106aeb2156a4984f06d37b0f" ], "markers": "python_version >= '3.8'", "version": "==6.86.2" }, "sortedcontainers": { "hashes": [ "sha256:25caa5a06cc30b6b83d11423433f65d1f9d76c4c6a0c90e3379eaa43b9bfdb88", "sha256:a163dcaede0f1c021485e957a39245190e74249897e2ae4b2aa38595db237ee0" ], "version": "==2.4.0" } }, "develop": {} }The text was updated successfully, but these errors were encountered: