一般的な問題については、診断ドキュメントを確認してください。 以下に再現する手順で、（おそらく欠陥のある）ワークフローの概要を説明しました。 私は自分のせいで数週間これに悩まされてきました、そしてこれが私のバグであることを望んでいます。
問題の説明
Pipfile.lockのデフォルトセクションにリストされている最後の外部パッケージが、ローカルおよび編集可能として誤ってマークされています
期待される結果
リストされている最後の外部パッケージは、引き続きpypiから提供されます
実結果
私のPipfile.lockには、この差分が含まれています。これは、明らかな理由でCIや他のユーザーを破壊します。
"version": "==1.25.10"
},
"wrapt": {
- "hashes": [
- "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
- ],
- "version": "==1.12.1"
+ "editable": true,
+ "path": "."
}
},
"develop": {
複製する手順
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[dev-packages]
flake8 = "3.8.3"
pytest = "5.4.3"
pytest-cov = "2.10.0"
termcolor = "1.1.0"
[packages]
mycli = {editable = true, path = "."}
[requires]
python_version = "3.7"
（mycliには、Pythonクリックのエントリポイントの作成を容易にするsetup.pyがあり、開発以外の依存関係を定義します）
プロジェクトはCLIユーティリティであり、リポジトリのクローンを作成し、次の方法でインストールします。
PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy
新しい依存関係を追加する開発者として、 setup.pyを編集して実行します。
pipenv lock
これにより、新しい依存関係だけでなく、不正な形式の最後のデフォルトの依存関係も含むPipfile.lockファイルが生成されます（その位置のアルファベットの終わり近くにある複数のパッケージ、具体的にはwraptおよびzipp ）
この問題を回避し、次の方法で正しいPipfile.lockを生成できます。
rm -rf Pipfile.lock .venv
そしてpipenv lock
私が取り組んでいるアプリケーションはプロプライエタリであり、環境の詳細が漏洩することを心配しているため、意図的にpipenv --support出力を省略しています（またはセキュリティチームが私に怒鳴っています：笑い:)。 スクラブして提供できる特定のスニペットがある場合は、すべてを前もってスクラブしたくありませんでした。
読んでくれてありがとう、そしてもう一度、私がただ馬鹿になっていることを願っています。
ありがとう！
gregflynn
全てのコメント9件
@patelamolと私はこれをpipenv2020.08.13で再現できます。
jmehnle
2020年10月01日
2018.11.26まで、すべての最新バージョンでこのバグが発生しました。 したがって、 2018.11.26はこの問題はありません。
patelamol
2020年10月02日
@jmehnleと@patelamolがコメントしたように、この場合、いくつかのパッケージで同様の問題が発生しています。
"zipp": {
"editable": true,
"path": "."
},
私の解決策は、pipfileロックを手動で編集することでした。これは、最新バージョンでは安全ではない/不健全です。
"zipp": {
"hashes": [
"sha256:43f4fa8d8bb313e65d8323a3952ef8756bf40f9a5c3ea7334be23ee4ec8278b6",
"sha256:b52f22895f4cfce194bc8172f3819ee8de7540aa6d873535a8668b730b8b411f"
],
"version": "==3.2.0"
}
このバグ修正ですぐにpipenvアップデートが出てくるのだろうか
ch3ck
2020年10月09日
@gregflynn @patelamolでは、この問題はマスターブランチに存在しますか？ 与えられた手順では再現できません
frostming
2020年10月27日
@gregflynn @patelamolでは、この問題はマスターブランチに存在しますか？ 与えられた手順では再現できません
きっと！ 以前にgithubからpipenvを実行したことがなく、READMEに手順が表示されなかったため、手順について詳しく説明します。
- gitのクローンを作成
pyenv virtualenv 3.7.9 pipenv&&pyenv local pipenv&&pip install -e .- 検証：
`` `
$ pipenv --version
pipenv、バージョン2020.8.13
$ ~/.pyenv/versions/pipenv/bin/pipenv --version
pipenv, version 2020.8.13.dev0
```
- 2020.8.13で新しいvenvを作成しました
- setup.pyに
stockquotes == 2.0.0を追加しました ~/.pyenv/versions/pipenv/bin/pipenv lock- サイコロなし、エラーが表示されます
"wrapt": {
- "hashes": [
- "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
- ],
- "version": "==1.12.1"
+ "editable": true,
+ "path": "."
}
},
@frostmingは、提案と
gregflynn
2020年10月27日
@gregflynn
- 2020.8.13で新しいvenvを作成しました
このステップはバグを再現するために重要ですか？ マスターPipenvで作成しましたが、再現できません。 Dockerイメージは、可能であれば非常に役立ちます
frostming
2020年10月28日
@gregflynn
- 2020.8.13で新しいvenvを作成しました
このステップはバグを再現するために重要ですか？ マスターPipenvで作成しましたが、再現できません。 Dockerイメージは、可能であれば非常に役立ちます
見た目は良いですが、以下の変更を加えても最新のマスターバージョンで再現できました。 ステップ4では、インストールスクリプトを更新しました。
-PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 pipenv install --deploy
+PIPENV_IGNORE_VIRTUALENVS=1 PIPENV_VENV_IN_PROJECT=1 $HOME/.pyenv/versions/pipenv/bin/pipenv install --deploy
そしてまだ得た：
"wrapt": {
- "hashes": [
- "sha256:b62ffa81fb85f4332a4f609cab4ac40709470da05643a082ec1eb88e6d9b97d7"
- ],
- "version": "==1.12.1"
+ "editable": true,
+ "path": "."
}
},
もっと試してみてください！ ありがとう
gregflynn
2020年10月28日
ああ、なんとか再現できました！ 重要な要素がVENV_IN_PROJECTであることに気づきませんでした。
frostming
2020年10月29日
ああ、なんとか再現できました！ 重要な要素がVENV_IN_PROJECTであることに気づきませんでした。
：raised_hands：すばらしいニュースです！ 申し訳ありませんが、Dockerfileを提供することを怠り、最初の読み取りでそのメモを見逃しました
gregflynn
2020年10月29日
関連する問題
jerzyk
·
3コメント
AkiraSama
·
3コメント
FooBarQuaxx
·
3コメント
hynek
·
3コメント
jeyraof
·
3コメント
最も参考になるコメント
@jmehnleと@patelamolがコメントしたように、この場合、いくつかのパッケージで同様の問題が発生しています。
私の解決策は、pipfileロックを手動で編集することでした。これは、最新バージョンでは安全ではない/不健全です。
このバグ修正ですぐにpipenvアップデートが出てくるのだろうか