-
-
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
Lock fails to resolve dependencies from private registry (GitLab) #5932
Comments
Temporary solution that worked for me is pinning pipenv to > pip install pipenv==2022.1.8
> pipenv lock |
The first source in the Pipfile is the default source, and all packages will be resolved against that unless otherwise specified with a secondary source. I am not sure I understand the step 2. Removing pypi.org as a source idea ... |
Does making |
Because GitLab automatically redirects to pypi, with |
No, it didn't. |
That makes sense then, yes I agree it should work -- are you able to view an html index of packages at that location of your custom source? |
If I navigate to |
I believe this is related to the other issue. As @matteius mentioned above, the resolving / locking mechanism uses only the first source for resolving dependencies. What this means in practice is that |
In the case of |
This should seemingly work, but for some reason I find this hasn't been working in practice when using |
Well I created a Gitlab trial, so have 30 days to figure this out 😆 but from first take, it appears that the index that redirect packages from pypi doesn't list those available packages on the index page. This gets complicated because some private indexes, such as one nexus I recently fixed hash collection for organize the hashes differently so unless we are careful fixing this, we will break other ones. Right now, the strategy is defined: https://github.com/pypa/pipenv/blob/main/pipenv/project.py#L294-L361 related: #5894 Basically I think we need to amend that method to check for the index_url and the package name, if its a 404, fall back to what it does today (maybe some refactor involved) but yeah -- pytorch, nexus, gitlab all do it slightly differently. |
@jonbiemond Hey, I am actually not able to reproduce this -- I setup a trial Gitlab, and the only thing I can note is when you grant the access token, you have to grant the right permissions for it to work, but in my case it does work:
|
@Mattieus I don’t think this is equivalent to the problem. You need a package inside the GitLab PyPI package registry that has all of its dependencies outside of it at pypi.org or equivalent. |
To be clear, "inside the GitLab PyPI package registry" means to have a package you've built and deployed to your GitLab project's PyPI package registry. To test, then you want a local Pipfile install* that uses both this package and some other package in the pypi.org registry.
|
@jonbiemond Hmmm... I have reconsidered the issue and realized you're right about this. I do have one project that is similar to yours, and I do have it working. However, I am now recollecting it didn't always work, but I am not 100% confident if the solution was to turn on the GitLab setting to forward non-GitLab requests to PyPI (not the default because of the exact reason the Pipfile.lock file works the way it does: security) or to turn off that setting. So, question (so I'm not assuming anything): Is this setting turned on in your GitLab project (it could also be a group-level setting)? I know the setting is currently turned off for my one project that is working, which I believe I did before my last build with it. Can you attempt to do the locking and install with this setting in both states: on and off? This is merely a diagnostic test for my hypothesis that you need to let pipenv do the resolving and collection for all packages. Thanks! |
This worked for me when trying to install Pytorch and using Azure Artifacts. Thanks :) |
Please recheck with |
Issue description
Packages successfully install, but
pipenv --lock
fails to resolve dependencies from my private GitLab registry.CRITICAL:pipenv.patched.pip._internal.resolution.resolvelib.factory:Could not find a version that satisfies the requirement mypackage (from versions: none)
I know there have been a lot of related issues, but I don't see any open with this exact bug.
Unlike #5767 I'm trying to install a private package without any dependencies on other private packages.
Actual result
When possible, provide the verbose output (
--verbose
), especially for locking and dependencies resolving issues.Steps to replicate
Pipenv version:
2023.6.18
$ pipenv --support
Pipenv version:
'2023.9.8'
Pipenv location:
'C:\\Users\\jonathan.biemond\\.virtualenvs\\my-project-sFQf-b2c\\lib\\site-packages\\pipenv'
Python location:
'C:\\Users\\jonathan.biemond\\.virtualenvs\\my-project-sFQf-b2c\\Scripts\\python.exe'
OS Name:
'nt'
User pip version:
'23.2.1'
user Python installations found:
PEP 508 Information:
System environment variables:
PATHEXT
PSEXECUTIONPOLICYPREFERENCE
PSMODULEPATH
PROGRAMFILES(X86)
TERM_SESSION_ID
COMMONPROGRAMW6432
PROGRAMW6432
VIRTUAL_ENV
ZES_ENABLE_SYSMAN
FIG_JETBRAINS_SHELL_INTEGRATION
USERNAME
ALLUSERSPROFILE
USERPROFILE
OS
USERDNSDOMAIN
PROCESSOR_ARCHITECTURE
IDEA_INITIAL_DIRECTORY
NUMBER_OF_PROCESSORS
COMSPEC
FPS_BROWSER_APP_PROFILE_STRING
PROCESSOR_LEVEL
PATH
WINDIR
USERDOMAIN_ROAMINGPROFILE
PUBLIC
DRIVERDATA
HOMEDRIVE
PROGRAMFILES
SESSIONNAME
LOGONSERVER
TERMINAL_EMULATOR
PROCESSOR_REVISION
TEMP
HOMEPATH
SYSTEMROOT
COMMONPROGRAMFILES(X86)
ONEDRIVE
ONEDRIVECONSUMER
USERDOMAIN
ONEDRIVECOMMERCIAL
SYSTEMDRIVE
COMPUTERNAME
PROGRAMDATA
TMP
LOCALAPPDATA
FPS_BROWSER_USER_PROFILE_STRING
APPDATA
COMMONPROGRAMFILES
PROCESSOR_IDENTIFIER
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PYTHONFINDER_IGNORE_UNSUPPORTED
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH
:C:\Users\jonathan.biemond\.virtualenvs\my-project-sFQf-b2c/Scripts;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\GitHub CLI\;C:\Pro gram Files\Docker\Docker\resources\bin;C:\Program Files\dotnet\;C:\Program Files\OpenSSL-Win64\bin;C:\Program Files\Git\cmd;C:\Users\jonathan.biemond\AppData\Local\Programs\Python\Python310\Scripts\;C:\Users\jonathan.biemond\AppData\Local\Programs\ Python\Python310\;C:\Users\jonathan.biemond\AppData\Local\Programs\Python\Launcher\;C:\Users\jonathan.biemond\AppData\Local\Microsoft\WindowsApps;C:\Users\jonathan.biemond\AppData\Local\JetBrains\mypackage\scripts;C:\Users\jonathan.biemond\AppData\Lo cal\Programs\Microsoft VS Code\bin;C:\Users\jonathan.biemond\AppData\Local\Programs\Git\cmd;C:\Users\jonathan.biemond\AppData\Local\Programs\Gpg4win\..\GnuPG\bin;C:\Users\jonathan.biemond\Portable\CMD\Nodejs;C:\Users\jonathan.biemond\AppData\Local\ GitHubDesktop\bin;C:\Users\jonathan.biemond\AppData\Roaming\postgresql\bin;C:\Users\jonathan.biemond\Portable\GUI\Sublime Text;C:\Users\jonathan.biemond\Portable\GUI\Vim\App\vim;
VIRTUAL_ENV
:C:\Users\jonathan.biemond\.virtualenvs\my-project-sFQf-b2c
Contents of
Pipfile
('C:\Users\jonathan.biemond\PycharmProjects\my-project\Pipfile'):Contents of
Pipfile.lock
('C:\Users\jonathan.biemond\PycharmProjects\my-project\Pipfile.lock'):Solutions attempted
Pipfile.lock
.pipenv lock --clear
pipenv
to the latest version.pipenv=2022.1.8
That last solution did work.
The text was updated successfully, but these errors were encountered: