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

Pipenv version 2022.8.31 #5374

Closed
dehhganii opened this issue Sep 23, 2022 · 5 comments
Closed

Pipenv version 2022.8.31 #5374

dehhganii opened this issue Sep 23, 2022 · 5 comments
Labels
Status: Awaiting Update ⏳ This issue requires more information before assistance can be provided.

Comments

@dehhganii
Copy link

Issue description

We work on a project which uses pipenv. In the version 2022.8.31 the building in Jenkins get failed. When I specify the version in our code the build is fine. However, all versions after 2022.8.30 make the build failed.

Expected result

The build should pass with no error

Actual result

The build failed due to: hudson.AbortException: script returned exit code 1

image

@matteius
Copy link
Member

@dehhganii I would need to see more of the --verbose output to try to determine which package, basically I believe this is similar to #5332 #5340 #5354 and #5358 -- there is likely some dependency that a setup.py imports which is not available during the install phase because it too is being installed. #4745 will provide better support for specifying arbitrary package install groups such as prereqs so that you can manage pre-install dependencies that way, but for now the guidance is to pipenv run pip install <package> for the package that is required by another setup.py to be installable.

@dehhganii
Copy link
Author

dehhganii commented Sep 23, 2022 via email

@matteius
Copy link
Member

@dehhganii I feel that there would be some other error in the pipenv sync --verbose output. Since the hashed packages installed as a group there is no good way to determine from the above output which package is causing you the install troubles.

@matteius matteius added the Status: Awaiting Update ⏳ This issue requires more information before assistance can be provided. label Sep 24, 2022
@dehhganii
Copy link
Author

dehhganii commented Sep 28, 2022

After our further investigation, we found out the real problem is that the hashes are not generated for our newly added / upgraded private libraries when locking Pipfile with pipenv version 2022.3.28. This issue seems to be fixed in the latest pipenv, but due to another issue (see #5021 and #5053) we can't use pipenv newer than 2022.3.28 to lock Pipfile at the moment. We'll keep working on solving the latter problem so that we can change to lock Pipfile with the latest pipenv. Thank you very much for you time and help!

@matteius
Copy link
Member

@dehhganii Just saw your response -- both of those issues are marked closed, but related to the use private pypi repositories and the requirement to have deterministic index restricted packages. It should still be possible for your use case to define the Pipfile in a way that correctly defines the index mapping for your packages. Let me know if you need help sorting this out, I'd be happy to help on the Python Developers slack group.

@matteius matteius closed this as completed Nov 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Awaiting Update ⏳ This issue requires more information before assistance can be provided.
Projects
None yet
Development

No branches or pull requests

2 participants