pip is able to search package but install fails wi

I have local pypi server, where I uploaded cffi package.

When I try to search, it return the package.

$ pip search -i https://localhost --trusted-host localhost cffi
cffi (1.11.4)  - 1.11.4

But when try to install, it gives error.

$ pip install -i https://localhost  --trusted-host localhost cffi==1.11.4
Collecting cffi==1.11.4
  Could not find a version that satisfies the requirement cffi==1.11.4 (from versions: )
No matching distribution found for cffi==1.11.4

I am running pypi server under apache webserver to handle https requests on centos.

I check the apache log /var/log/httpd/ssl_access_log, for install command. Its return 200 for GET Call.

127.0.0.1 - - [25/Jan/2018:16:46:23 +0000] "GET /cffi/ HTTP/1.1" 303 -
127.0.0.1 - - [25/Jan/2018:16:46:23 +0000] "GET /simple/cffi/ HTTP/1.1" 200 339

I check the log again. For celery it works, after that for cffi it fails.

127.0.0.1 - - [25/Jan/2018:16:50:58 +0000] "GET /celery/ HTTP/1.1" 303 -
127.0.0.1 - - [25/Jan/2018:16:50:58 +0000] "GET /simple/celery/ HTTP/1.1" 200 321
127.0.0.1 - - [25/Jan/2018:16:50:58 +0000] "GET /packages/celery-4.0.2-py2.py3-none-any.whl HTTP/1.1" 200 396437
127.0.0.1 - - [25/Jan/2018:16:50:59 +0000] "GET /cffi/ HTTP/1.1" 303 -
127.0.0.1 - - [25/Jan/2018:16:50:59 +0000] "GET /simple/cffi/ HTTP/1.1" 200 339

The problem is, for cffi its not redirect to /packages/cffi-1.11.4-cp35-cp35m-manylinux1_x86_64.whl. While in celery its goes to /packages/celery* after GET /simple/celery/.

I tried to curl, to check if there is change in response between these 2 packages, but there is not difference.

$ curl -k https://localhost/simple/celery/ -i
HTTP/1.1 200 OK
Date: Thu, 25 Jan 2018 16:59:27 GMT
Server: Apache/2.2.15 (CentOS)
Content-Length: 321
Connection: close
Content-Type: text/html; charset=UTF-8

    <html>
        <head>
            <title>Links for celery</title>
        </head>
        <body>
            <h1>Links for celery</h1>
                 <a href="/packages/celery-4.0.2-py2.py3-none-any.whl#md5=3ff97b53107b491baeb42f662be14a06">celery-4.0.2-py2.py3-none-any.whl</a><br>
        </body>
    </html>
$ curl -k https://localhost/simple/cffi/ -i
HTTP/1.1 200 OK
Date: Thu, 25 Jan 2018 16:59:29 GMT
Server: Apache/2.2.15 (CentOS)
Content-Length: 339
Connection: close
Content-Type: text/html; charset=UTF-8

    <html>
        <head>
            <title>Links for cffi</title>
        </head>
        <body>
            <h1>Links for cffi</h1>
                 <a href="/packages/cffi-1.11.4-cp35-cp35m-manylinux1_x86_64.whl#md5=c9478cf605b4eb2755fa322cc2bf3ddf">cffi-1.11.4-cp35-cp35m-manylinux1_x86_64.whl</a><br>
        </body>
    </html>

Two most common problems when facing this issue are either platform mismatch or python version mismatch.

python version check

Check what python version your default pip refers to - is it the python3.5's pip?

$ pip -V | grep -o "(.*)"

will give you the info. If default pip refers to some other python version, invoke the python3.5's pip directly with pip3.5:

$ pip3.5 install -i https://localhost  --trusted-host localhost cffi==1.11.4

platform check

Try explicitly downloading the cffi package for the manylinux1_x86_64 platform - will the wheel download?

$ pip download cffi --only-binary=:all: --platform manylinux1_x86_64 -i https://localhost --trusted-host localhost

If the download succeeds, you have a platform mismatch on your target machine. Check what platform is recognized by pip:

$ python3.5 -c "import pip; print(pip.pep425tags.get_platform())"

ABI check

A less common problem is the ABI mismatch: you can check your platform's ABI with

$ python3.5 -c "import pip; print(pip.pep425tags.get_abi_tag())"

This string should match the prefix in the wheel name that comes before the platform tag, so in your case, your ABI should be cp35m.

If you get the macosx_10_13_x86_64 platform tag, this means you have MacOS High Sierra. On your local PyPI server, you have uploaded the cffi wheel that can be installed on linux only (manylinux wheel). You won't be able to install it on MacOS High Sierra. The thing is, cffi package ships code partly written in C and compiled for the target platform only. You have three possibilities to solve this:

The simplest solution: download the macosx_10_13_x86_64 wheel from PyPI and upload it to your local server alongside the manylinux1 wheel. Now the linux client will get the wheel compiled for linux and you will get the wheel compiled for MacOS when running pip install cffi.
The "DIY" solution: download the source tar installer from PyPI and upload it to your local server alongside the manylinux1 wheel. Now the linux client will get the compiled wheel and MacOS and Windows clients will get the source tar, where they are forced to compile the contained C code locally - if the OS does not provide the right tools, the installation will fail.
Configure the local server to proxy the PyPI: if a package is requested, but not found on your local server, it passes the request through to the pypi.python.org and if the package is found in the public repository, it is downloaded and passed through your local server as if was found there. Not sure, however, if your server supports this feature. We use devpi where it is enough to tell your index that it should have root/pypi among its bases: devpi index -m user/index bases=root/pypi.

Note that these solutions are not mutually excluding: you can combine 1 with 2 (linux clients will get manylinux1 wheels, High Sierra gets macos_10_13 wheel, the rest get the source tar) and even 1, 2 and 3 alltogether. It all depends on what you want/need/can to upload and maintain on your local server.