Pip: pernyataan saat menggunakan --no-cache-dir di 19.0

Hal yang sama terjadi dengan:
Python v3.6.8
pip version 18.1
di
Ubuntu:latest gambar.

@snstanton, gambar dasar apa yang Anda gunakan? Saya juga melihat masalah serupa di pip v18.1

Saya punya masalah yang sama persis.
di sisi saya, tampaknya tidak masalah paket / distribusi mana yang saya coba instal

Saya melihat ini bahkan tanpa set --no-cache-dir . Ini terjadi untuk semua paket yang saya coba instal, meskipun paket tersebut sudah diinstal.

• versi pip: 19.0
• Versi Python: 3.6.0
• OS: Ubuntu 14.04.4 LTS (GNU / Linux 3.13.0-91-generik x86_64)

Saya harus mencatat bahwa dalam kasus saya, saya melihatnya ketika menjalankan pip dengan kombinasi sudo -H dan bash -l -c .

$ sudo -H bash -l -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Looking in indexes: https://pypi.org/simple, http://pypi.lan.cogtree.com/cogtree/simple/
Collecting hypothesis
  Downloading http://pypi.lan.cogtree.com/cogtree/simple/hypothesis/hypothesis-4.1.0-py3-none-any.whl (238kB)
    100% |████████████████████████████████| 245kB 120.5MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Exception:
Traceback (most recent call last):
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/data/virtualenvs/events_beta/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

Menjalankan perintah yang sama tanpa -l pada bash -c , atau tanpa melibatkan bash -l -c sama sekali, semuanya bekerja dengan baik.

$ sudo -H bash -c  "/data/virtualenvs/events_beta/bin/pip install hypothesis"
Collecting hypothesis
  Downloading https://files.pythonhosted.org/packages/89/7b/d6206dcde963139daa03a1d85b0c3428cb3ebf2ae8de3244b14a63e22680/hypothesis-4.1.0.tar.gz (180kB)
    100% |████████████████████████████████| 184kB 33.7MB/s
Requirement already satisfied: attrs>=16.0.0 in /data/virtualenvs/events_beta/lib/python3.6/site-packages (from hypothesis) (18.2.0)
Building wheels for collected packages: hypothesis
  Building wheel for hypothesis (setup.py) ... done
  Stored in directory: /root/.cache/pip/wheels/10/12/eb/4ab734432e8466d545c8501f531458845b45e8c4427d5367f9
Successfully built hypothesis
Installing collected packages: hypothesis
Successfully installed hypothesis-4.1.0

Menariknya, jika saya menjalankan perintah yang sama tanpa melibatkan sudo atau bash , masih gagal dengan kesalahan yang sama, jadi sepertinya ini masalah perizinan yang aneh.

Solusi lain untuk beberapa situasi

Bagi orang yang terkena bug ini karena virtualenv secara otomatis menginstal versi pip terbaru, Anda dapat mengatasinya dengan memberikan virtualenv opsi --no-download , atau menyetel VIRTUALENV_NO_DOWNLOAD=1 .

Tetapi ketahuilah bahwa ini mungkin memberi Anda versi pip yang sangat lama, tergantung pada terakhir kali Anda meningkatkan virtualenv.

Ini juga bekerja dengan tox: VIRTUALENV_NO_DOWNLOAD=1 tox .

untuk apa nilainya: itu juga gagal dengan kesalahan yang sama jika paket sudah diinstal:

gregory.starck<strong i="6">@canon</strong>:~/tmp$ ./venv/bin/pip install --no-cache-dir six ; echo $?
Looking in indexes: http://pypi:3141/root/ax/+simple/
Requirement already satisfied: six in ./venv/lib/python3.6/site-packages (1.12.0)
Exception:
Traceback (most recent call last):
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/home/gregory.starck/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
2
gregory.starck<strong i="7">@canon</strong>:~/tmp$

Mengalami masalah yang sama. Akhirnya memasang pin versi pip sebagai perbaikan untuk saat ini.

pip install --upgrade pip==18.1

Masalahnya adalah dengan assert yang gagal, jadi pengaturan env PYTHONOPTIMIZE = 1 (atau dengan parameter -O) membuat kesalahan ini hilang.
Baru saja mengujinya.
Solusi ini berfungsi karena python mengoptimalkan penghapusan kode semua pernyataan sebagai salah satu hal.
Jangan gunakan = 2 (atau -OO), karena ini menghapus docstrings dan penelusuran balik lainnya akan muncul - beberapa kode ingin mengoperasikannya.

Sepertinya seseorang tahu bahwa ini mungkin akan menjadi masalah ( sumber ):

        # TODO: This check fails if --no-cache-dir is set. And yet we
        #       might be able to build into the ephemeral cache, surely?
        building_is_possible = self._wheel_dir or (
            autobuilding and self.wheel_cache.cache_dir
        )
        assert building_is_possible

https://github.com/pypa/pip/pull/5884 sepertinya ini adalah perubahan terkait yang bisa menyebabkan hal ini?

Sepertinya pengelola pip harus mengembalikan rilis 19 terbaru untuk mengatasi perubahan yang mengganggu ini?
Catatan rilis 19.0: https://github.com/pypa/pip/blob/master/NEWS.rst#190 -2019-01-22

PEMBARUAN: tidak mencoba untuk melemparkan aspersi di sini, hanya menyarankan sebagai salah satu cara untuk segera membuka blokir orang yang terkena dampak ini karena rilis telah _just_ terjadi. Melanjutkan dengan perbaikan terbaru juga berfungsi. Saya menghargai kerja keras komunitas yang mendukung alat misi kritis ini, dan setuju dengan sentimen di bawah ini tentang postmortem untuk belajar dari kesalahan dan mencegah masalah di masa mendatang. Sementara itu, kami melakukan hal yang sama secara internal, yang berarti sejumlah besar penyematan versi pip di semua tempat :)

PR yang menambahkan komentar TODO juga memiliki komentar ini di balasannya: https://github.com/pypa/pip/pull/5743/files#r215832743

Berdasarkan komentar itu dan juga komentator di atas mengatakan bahwa melewati PYTHONOPTIMIZE=1 membuat kesalahan hilang, sepertinya hanya menghapus pernyataan mungkin merupakan perbaikan yang benar (terlepas dari pertanyaan memutar kembali).

Ya, ketika saya menghapus pernyataan itu, paket menginstal dengan baik dengan --no-cache-dir . Dalam hal ini, dikatakan Running setup.py install bukan Building wheel untuk paket sdist.

Ini juga terjadi pada proyek saya. Saya dapat mereproduksi ini dalam gambar Docker yang dibangun FROM ubuntu:bionic dan FROM centos:centos7 mana saya menginstal Python 3 dari sumber (di sini adalah Gist yang menunjukkan contoh yang gagal untuk kedua gambar Docker itu jika itu mungkin bisa membantu). Untuk requirements.txt dalam contoh di Gist dan

$ pip3 install --upgrade pip setuptools wheel
Requirement already up-to-date: pip in /usr/lib/python3.6/site-packages (19.0)
Requirement already up-to-date: setuptools in /usr/lib/python3.6/site-packages (40.6.3)
Requirement already up-to-date: wheel in /usr/lib/python3.6/site-packages (0.32.3)

kemudian

$ pip3 install --upgrade --no-cache-dir -r requirements.txt

gagal dengan

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError

tapi

$ pip3 install --upgrade -r requirements.txt

bekerja dengan baik seperti yang diharapkan.

Saya terutama memukul ini dengan tox + docker + ENV PIP_NO_CACHE_DIR=off

Solusi saya adalah menggunakan plugin tox-virtualenv-no-download untuk mencegah pip memperbarui otomatis

Kami juga memiliki --no-cache-dir dalam pemasangan kami di dalam Docker untuk menjaga gambar tetap kecil. Solusi kami adalah --cache-dir=/pipcache dan kemudian rm -rf /pipcache dalam langkah RUN sehingga tidak pernah berakhir di gambar.

Pengembangan perangkat lunak sulit dan bug seperti ini akan selalu terjadi. Tentunya tidak ada yang harus menyalahkan pengelola pip atau kontributor atas kejadian ini.

Namun, saya akan menyarankan bahwa bug ini layak untuk analisis post-mortem di pihak tim pip, karena jumlah peluang (yang terlewat) untuk bug ini telah ditangkap sebelum tergelincir ke rilis umum. Sebagai contoh:

• pengujian otomatis fungsionalitas inti seperti --no-cache-dir
• pra-lakukan, pra-gabungkan, atau pra-rilis memeriksa bahwa menandai (atau melarang) TODO s
• tinjauan pra-penggabungan (manusia) dari semua komentar tinjauan yang belum terselesaikan di PR (Github mengotomatiskan sebagian besar utas komentar tinjauan ketika kode terkait mereka telah diubah, dan baru-baru ini memungkinkan Anda menandai secara manual utas komentar ulasan sebagai diselesaikan)
• perubahan dalam proses rilis - mengapa tidak merilis beta dulu dan kemudian menunggu beberapa minggu sebelum rilis umum?
• dll

Postmortem dapat menghasilkan sejumlah perbaikan yang bermanfaat untuk memastikan bahwa perangkat lunak yang merupakan inti proyek Python pip tidak dikirimkan dengan bug sebesar ini di masa mendatang.

Saya dapat mereplikasi bug ini. Menghapus --no-cache-dir akan memperbaikinya. Karena saya tidak ingin itu ada di gambar buruh pelabuhan saya, saya menggunakan solusi @coderanger yang diusulkan. Cheers 🌈🍰🌈

Ini tampak seperti duplikat dari Masalah # 6166

Dockerfile reproduksi cepat dan mudah:

FROM buildpack-deps:buster
ENV LANG C.UTF-8
ENV LC_ALL C.UTF-8
RUN apt-get update && apt-get install -y --no-install-recommends python3-dev && rm -rf /var/lib/apt/lists/*
RUN curl https://bootstrap.pypa.io/get-pip.py | python3 - --no-cache-dir

menghapus pernyataan saja mungkin merupakan perbaikan yang benar

Tidak juga - saya pikir kita harus menyimpan ini di sana untuk membangun non-ephem. Saya akan mengajukan PR perbaikan bug, setelah saya selesai dengan sarapan. :)

@pradyunsg periksa PR saya untuk tes yang gagal

Bagi saya, pip v19.0 akan gagal menginstal apa pun jika opsi --no-cache (atau --no-cache-dir ) digunakan.

Saya telah mengajukan # 6171 sebagai perbaikan bug untuk masalah ini. Bisakah orang-orang dari utas ini mencoba PR itu dan memverifikasi bahwa itu benar-benar memperbaiki masalah ini?

PS: Terima kasih @tgs telah mengajukan PR untuk membantu memperbaiki masalah ini dengan cepat! :)

wfm, terima kasih atas perbaikannya!

$ pip install pip --upgrade
Requirement already up-to-date: pip in ./venv/lib/python3.6/site-packages (19.0)
$ pip install --no-cache-dir pip
Requirement already satisfied: pip in ./venv/lib/python3.6/site-packages (19.0)
Exception:
Traceback (most recent call last):
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/tmp/venv/lib/python3.6/site-packages/pip/_internal/wheel.py", line 848, in build
    assert building_is_possible
AssertionError
$ pip install git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
Collecting git+https://github.com/pradyunsg/pip@fix/pep-517-building-assertion
  Cloning https://github.com/pradyunsg/pip (to revision fix/pep-517-building-assertion) to ./pip-req-build-g_3qep31
Branch 'fix/pep-517-building-assertion' set up to track remote branch 'fix/pep-517-building-assertion' from 'origin'.
Switched to a new branch 'fix/pep-517-building-assertion'
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: pip
  Building wheel for pip (PEP 517) ... done
  Stored in directory: /tmp/pip-ephem-wheel-cache-sb1_muik/wheels/bd/86/cd/7688dba746eabc598fb37d4a93e2ff9bd05a6d9f907ee7b6cd
Successfully built pip
Installing collected packages: pip
  Found existing installation: pip 19.0
    Uninstalling pip-19.0:
      Successfully uninstalled pip-19.0
Successfully installed pip-19.1.dev0
$ pip install --no-cache-dir astpretty  # downloads a wheel
Collecting astpretty
  Downloading https://files.pythonhosted.org/packages/9d/10/cb0c3a3edb16f45be05bdba7f37798fcddb8cf085def8cb6e62b2ad7c711/astpretty-1.4.1-py2.py3-none-any.whl
Installing collected packages: astpretty
Successfully installed astpretty-1.4.1
$ pip install --no-cache-dir simplejson  # requires building
Collecting simplejson
  Downloading https://files.pythonhosted.org/packages/e3/24/c35fb1c1c315fc0fffe61ea00d3f88e85469004713dab488dee4f35b0aff/simplejson-3.16.0.tar.gz (81kB)
    100% |████████████████████████████████| 81kB 1.0MB/s 
Installing collected packages: simplejson
  Running setup.py install for simplejson ... done
Successfully installed simplejson-3.16.0

Saya berharap segera menggabungkan PR6171 dan merilis versi 19.0.1

Orang harus benar-benar menyematkan pip di CI seperti yang akan Anda lakukan untuk paket atau ketergantungan lainnya, IMO. Jika tidak, Anda tidak memiliki reproduktifitas dan risiko kerusakan mendadak. Dengan memasang pin, Anda dapat memeriksa berbagai hal sebelumnya dan meningkatkan kemampuan Anda sendiri.

Orang harus benar-benar menyematkan pip di CI seperti yang akan Anda lakukan untuk paket atau ketergantungan lainnya, IMO. Jika tidak, Anda tidak memiliki reproduktifitas dan risiko kerusakan mendadak. Dengan memasang pin, Anda dapat memeriksa berbagai hal sebelumnya dan meningkatkan kemampuan Anda sendiri.

@cjerdonek : Saya setuju dengan Anda bahwa - dari sudut pandang pip pengguna - adalah ide yang bagus untuk menyematkan pip dalam banyak konteks (mungkin sebagian besar). Paling tidak, jika Anda tidak memasang pin, Anda harus tahu bahwa Anda sedang mempertaruhkan hal semacam ini, dan Anda tidak dapat mengeluh kepada pengelola pip jika itu terjadi!

Namun ... dari perspektif pengelola pip (dan lebih luas lagi dari perspektif tim inti PyPA atau Python) saya pikir akan lebih bijaksana untuk melihat fakta bahwa banyak orang tidak menyematkan pip sebagai aset. Ini tidak berwujud, tetapi menunjukkan kepercayaan yang besar oleh basis pengguna. (Sebagai tambahan, mungkin berlawanan dengan intuisi, menurut pengalaman saya Seringkali sebagian besar alat inti tidak disematkan seperti kebanyakan dependensi. Misalnya, di tempat saya bekerja, python sendiri biasanya secara efektif disematkan ke versi minor - versi tambalan baru secara otomatis mendapatkan diambil oleh bentukan baru. Menurut saya ini menunjukkan tingkat kepercayaan yang tinggi yang dimiliki pengguna terhadap alat inti dan pemeliharannya.)

Insiden seperti ini mengikis kepercayaan itu. Build CI yang rusak bukanlah masalah sebenarnya (seperti yang Anda katakan, Anda harus menyematkan pip dalam build CI atau menyadari apa yang Anda pertaruhkan), tetapi merupakan gejala - atau lebih tepatnya, peringatan yang berkorelasi - dari kepercayaan yang terkikis.

Itulah mengapa saya mengusulkan agar insiden ini layak dilakukan melalui proses postmortem (tanpa cela). Tidak ada pengelola pip merasa tidak enak sekarang, tetapi, ini adalah masalah serius dan harus diperiksa untuk perbaikan.

Ya, insiden seperti ini tidak membantu membangun kepercayaan. Kami akan melakukan pemeriksaan mayat untuk mencari cara bagaimana menghindarinya (kami melakukannya setelah setiap rilis karena selalu ada ruang untuk perbaikan).

Terima kasih untuk (kebanyakan) mempertahankan wacana yang tepat dan untuk komentar konstruktif kalian! Biasanya, segala sesuatunya jauh lebih korosif bagi kami ketika ada masalah seperti ini. :)

Tidak kurang, ada beberapa laporan bug lain untuk diperiksa dan kami akan segera memiliki 19.0.1.

Saya pikir hal utama di sini adalah bahwa ini telah mengungkapkan bahwa kami tidak memiliki tes yang memadai untuk membangun di bawah --no-cache-dir . Pengujian tambahan di area tersebut akan sangat membantu dalam menghindari regresi seperti ini, dan secara lebih umum tinjauan tentang fungsionalitas "kunci" apa yang kurang diuji akan sangat membantu.

Sebagai pengelola pip, saya akan mengatakan bahwa satu masalah yang saya miliki adalah mengetahui apa yang dianggap orang sebagai fungsi "kunci". Secara pribadi, saya akan berasumsi --no-cache-dir cukup niche, jadi jelas intuisi saya tidak dapat diandalkan dalam kasus ini :-) Oleh karena itu, umpan balik seperti ini sangat berharga.

Saya pikir itu dapat segera dirilis 19.0.1 hanya untuk bug ini, bagaimanapun, ini penting dan mendesak. Laporan bug lain dapat diselesaikan di 19.0.2 setelah hari.

Sebagai pengelola pip, saya akan mengatakan bahwa satu masalah yang saya miliki adalah mengetahui apa yang dianggap orang sebagai fungsi "kunci". Secara pribadi, saya akan berasumsi --no-cache-dir cukup niche, jadi jelas intuisi saya tidak dapat diandalkan dalam kasus ini :-) Oleh karena itu, umpan balik seperti ini sangat berharga.

Satu-satunya alasan mengapa saya menggunakan --no-cache-dir , adalah untuk menginstal mpi4py .
Dengan cara ini, saya dapat memastikan bahwa itu diunduh ulang dan dibangun kembali sebelum menginstal, memastikan bahwa setiap perubahan yang dibuat pada distribusi MPI saya diperhitungkan.

Masalah yang sama di sini, dapat mereproduksinya di luar sistem CI kami. Sebagai solusinya, kami telah menurunkan versi ke pip 18.1.0 dan semuanya berfungsi:

pip install pip==18.1.0

Berharap dan segera tingkatkan.

Saya akan gunakan:

pip install "pip!=19.0"

Harapan 19.1 sudah diperbaiki :)

Saya menduga kita akan segera memiliki 19.0.1 dengan perbaikan untuk masalah yang muncul.

Saya ingin tahu apakah menyertakan --no-use-pep517 bersama dengan --no-cache-dir adalah solusi lain untuk masalah ini, seperti untuk masalah terkait PEP 517 lainnya: https://github.com/pypa/pip / issues / 6163 # Issuecomment -456772043

Sebagai pengelola pip, saya akan mengatakan bahwa satu masalah yang saya miliki adalah mengetahui apa yang dianggap orang sebagai fungsi "kunci". Secara pribadi, saya akan berasumsi --no-cache-dir cukup khusus, jadi jelas intuisi saya tidak dapat diandalkan dalam kasus ini :-) Oleh karena itu, umpan balik seperti ini sangat berharga.

FWIW: Saya cukup sering menggunakan --no-cache-dir saat membuat image Docker, untuk mencegah kemungkinan cache cruft tertinggal di lingkungan yang tidak akan berguna.

Orang harus benar-benar menyematkan pip di CI seperti yang akan Anda lakukan untuk paket atau ketergantungan lainnya, IMO. Jika tidak, Anda tidak memiliki reproduktifitas dan risiko kerusakan mendadak. Dengan memasang pin, Anda dapat memeriksa berbagai hal sebelumnya dan meningkatkan kemampuan Anda sendiri.

Di banyak lingkungan, pip bukanlah ketergantungan. Ini diinstal saat membuat virtualenv.

Dan omong-omong, tidak menguji di sana untuk melihat apakah produk Anda berfungsi dengan versi terbaru. Menyematkan semuanya hanya mengarah ke versi lama yang digunakan. Dan memperbarui akan segera menjadi tugas yang tidak berani dimulai oleh siapa pun. Berada di sana, lakukan itu. Jadi pendapat saya adalah menyematkan hanya jika benar-benar diperlukan. Dan coba perbaiki masalah segera setelah terjadi.

pip 19.0.1 keluar dengan perbaikan untuk masalah ini.

Saya sangat senang melihat perbaikan versi 19.0.1 yang baru, tetapi masih mengalami masalah. Saya juga membuat image Docker dengan --no-cache-dir yang berfungsi baik dengan pip <19.0. Ada lagi yang mengerti?

Exception:
Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/usr/lib/python3.6/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/usr/lib/python3.6/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError

Saya sangat senang melihat perbaikan versi 19.0.1 yang baru, tetapi masih mengalami masalah. Saya juga membuat image Docker dengan --no-cache-dir yang berfungsi baik dengan pip <19.0. Ada lagi yang mengerti?

memperbaiki bekerja untuk saya dengan 19.0.1 - Saya menduga Anda memiliki cache layer docker yang membingungkan Anda? - coba pip --version untuk memeriksa versi yang Anda gunakan

Saya memiliki versi Python dan pip memeriksa semua file Docker saya, dan melaporkan 19.0.1 dengan benar.

@dmulter Saya membangun kembali gambar Docker saya di Gist saya dari awal pagi ini dan semuanya bekerja dengan baik di sana dengan v19.0.1 . Bisakah Anda membagikan Dockerfile Anda dalam Gist juga sehingga kita semua dapat melihatnya?

Hanya membersihkan semuanya lagi hanya untuk memastikan. Inilah Dockerfile dan keluaran build saya.

Lihat catatan saya pada output build untuk perintah buruh pelabuhan yang digunakan.

Apakah ada perbaikan untuk pip3? Inilah kesalahan yang saya dapatkan ...

> pip3 install --upgrade 'pip>=19.01' setuptools

  Could not find a version that satisfies the requirement pip>=19.01 (from versions: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1, 0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2, 0.8.3, 1.0, 1.0.1, 1.0.2, 1.1, 1.2, 1.2.1, 1.3, 1.3.1, 1.4, 1.4.1, 1.5, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.1.0, 6.1.1, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.1.0, 7.1.1, 7.1.2, 8.0.0, 8.0.1, 8.0.2, 8.0.3, 8.1.0, 8.1.1, 8.1.2, 9.0.0, 9.0.1, 9.0.2, 9.0.3, 10.0.0b1, 10.0.0b2, 10.0.0, 10.0.1, 18.0, 18.1, 19.0)
No matching distribution found for pip>=19.01
You are using pip version 10.0.1, however version 19.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

@MrAtheist Anda memiliki kesalahan ketik kecil / tidak ada desimal. Rilis patch adalah 19.0.1 tetapi Anda memiliki 19.01 tertulis.

Ups kesalahan saya, tapi bagaimanapun juga, versi yang mungkin tidak mencantumkan 19.0.1 ... ¯_ (ツ) _ / ¯

Seperti @dulter, saya merasa masalah ini masih belum terselesaikan. Ekstrak dari keluaran build:

. venv/bin/activate;  python -m pip install --upgrade pip; python -m pip install ndg_httpsclient; python -m pip install . -i https://xxxx.yyyy.com/simple --upgrade --no-cache-dir flask
DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Requirement already up-to-date: pip in ./venv/lib/python2.7/site-packages (19.0.1)
...
Requirement already satisfied, skipping upgrade: pycparser in ./venv/lib/python2.7/site-packages (from cffi>=1.1->bcrypt>=3.1.3->paramiko<3.0,>=1.10->Fabric==1.14.0->conference-gll-load-test===0.0.1-SNAPSHOT) (2.19)
Exception:
Traceback (most recent call last):
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/cli/base_command.py", line 176, in main
    status = self.run(options, args)
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/commands/install.py", line 346, in run
    session=session, autobuilding=True
  File "/mnt/jenkins/workspace/venv/local/lib/python2.7/site-packages/pip/_internal/wheel.py", line 886, in build
    assert have_directory_for_build
AssertionError
make: *** [install] Error 2

Sebelumnya di utas saya telah bertanya apakah menyertakan --no-use-pep517 bersama dengan --no-cache-dir membuat semuanya berfungsi untuk orang, tetapi saya tidak melihat balasan. Untuk orang yang masih merasakan opsi, dapatkah Anda mencobanya?

Menambahkan opsi --no-use-pep517 memperbaiki masalah saya. Harapan yang membantu mempersempit segalanya.

pip 19.0.1 bekerja untuk saya di virtualenv. Tapi di dalam Jenkins (Shining Panda) masih gagal. Menambahkan --no-use-pep517 memperbaiki masalah

Saya buka kembali karena beberapa orang masih mengalami masalah yang sama.

Saya juga dapat mengonfirmasi bahwa --no-use-pep517 memperbaiki masalah saya setelah meningkatkan ke pip 19.0.1 tidak.

Tetapi mengapa semua proyek itu harus beradaptasi setiap kali pip mendapatkan versi baru?

Atas permintaan @pradyunsg , saya telah membuka terbitan baru (https://github.com/pypa/pip/issues/6197) khusus untuk AssertionError dalam rilis 19.0.1, karena lebih sempit dalam ruang lingkup dan akan membutuhkan investigasi baru. Jadi saya menutup kembali masalah ini.

Mengalami masalah yang sama. Akhirnya memasang pin versi pip sebagai perbaikan untuk saat ini.

pip install --upgrade pip==18.1

atau FROM python:3.6-alpine dapat diubah menjadi FROM python:3.6.7-alpine

Utas ini telah dikunci secara otomatis karena tidak ada aktivitas baru-baru ini setelah ditutup. Silakan buka masalah baru untuk bug terkait.