Pipenv: Pipfileの新しい「pre」構文

私はこのタスクに自分自身を割り当てていますが、コードを入力するのに時間がかかる場合があります

@frostmingこの提案は、最近ここで行った変更とどのように相互作用しますか？

私のPRの変更点は、CLIからワイルドカードバージョンをインストールするときに、Pipfileが変更されないことです。

ここでの提案では、 pipenv install mypkg --preを実行すると、エントリを置き換えてもかまいませんね。 最も簡単な方法は、追加の引数preをadd_package_to_pipfileに追加することです。

それが実現したとき、私は喜んでお手伝いします。

こんにちは！ これに関する更新や見積もりはありますか？

これに進展がない場合は、それを実現したいと思います。それ以外の場合は、virtualenv / pipに戻ります。

@frostmingあなたの提案では、それはどのようにしてPipfileを検索することになりますか？ 要件が実際にどのように解析されるのかよくわからないので、コードを簡単に参照しました。 完全にボールパーキング、訂正してください。 次のような構文に従う必要がありますか？
編集：最初の問題ごとのコメント：

...
mypkg = { version = "*", pre="true"}
...

私はそれに取り組んでいましたが、完全にやり直す必要があるリゾルバーにいくつかの変更がありました。 私はそれについていくつかの助けを得てうれしいです

allow_prereleasesまたは--preが提供されていても、特定のプレリリースバージョンへのピンが機能することがわかりました

@gsemetこれを実現するためにどこにいますか？ これを推進するのを手伝っていただければ幸いです

iveは奇妙な方法でそれを解決しました、間違いなく@gsemetが提案したようにそれを利用可能にするべきです。 ただし、編集可能なルートに移動し、pypaのパッケージではなくリリースタグを直接指定することで、pipfileの残りの部分を壊すことなく、単一のパッケージをプレリリースとして修正できます。

marshmallow = {editable = true,ref = "3.0.0rc4",git = "https://github.com/marshmallow-code/marshmallow.git"}

@gsemetこれを実現するためにどこにいますか？ これを推進するのを手伝っていただければ幸いです

iveは奇妙な方法でそれを解決しました、間違いなく@gsemetが提案したようにそれを利用可能にするべきです。 ただし、編集可能なルートに移動し、pypaのパッケージではなくリリースタグを直接指定することで、pipfileの残りの部分を壊すことなく、単一のパッケージをプレリリースとして修正できます。

marshmallow = {editable = true,ref = "3.0.0rc4",git = "https://github.com/marshmallow-code/marshmallow.git"}

回避策をありがとう。 これは、次のようにeditable = trueなくても機能することに注意してください。

marshmallow = {ref = "3.0.0rc4",git = "https://github.com/marshmallow-code/marshmallow.git"}

@ekhaydarov本当に何もしませんでした、ごめんなさい:(赤ちゃんがいて、一度リゾルバーで失われました:(今のところこの気の毒なリゾルバーのためにそれを掘り下げる意志はあまりありません： '（

さて、私が概説しようとしているのは、この機能要求に対するバグまたはより強力なインセンティブのいずれかである可能性があります...

このPipfileがあると仮定します。

[dev-packages]
my_package = { path = ".", editable=true }

そして、 .のパッケージはプレリリースバージョンを構築し、その後、全体の事柄は次のように終わります。

[pipenv.exceptions.ResolutionFailure]:       ResolutionFailure: ERROR: ERROR: Could not find a version that matches my_package 

これはバグのどちらかです。なぜなら、人々がpath="."指定すると、プレリリース/アルファ/ベータステータスに関係なく（特に[dev-packages]にある場合）、 .あるものはすべてインストールされると期待するからです。 [dev-packages]セクション）またはこの問題を解決することは強力なインセンティブです。解決されない場合、pipenvを使用してアルファ/ベータ/プレリリースバージョンを開発する他の方法がないためです。 パッケージが[dev-packages]セクションにある場合、ユーザーは、それらのプレリリースバージョンを明示的に許可しなくても、アルファ、ベータ、およびプレリリースバージョンがインストールされることを期待するだろうと主張することもできます。

依存関係でpath=が指定されている場合はプレリリースを検討し、次に[dev-packages]未満のすべてのパッケージでプレリリースを検討するために、別の問題を開く必要があるかどうかを教えてください。

こんにちは。
pipenv install -e .または-e deps/mysubmoduleを使用しても、プリバージョンを使用しても問題はありません。 それが-eから来ているかどうかわからない。

しかし、実際には、現在のモジュールでこの機能を使用するのをやめました。複雑すぎて維持できません。 Pipfile[.lock]依存関係を宣言させ、ターゲットを含むMakefileに次のことを実行させます。

install-dev:
    pipenv install --dev --ignore-pipfile --deploy
    pipenv run pip install -e .

ボーナス：

update:
    pipenv update --clear

ここで提供される完全な

ハ！ おかげで、私の問題が少し違うことに気付くのを手伝ってくれました。

path='./'のプロジェクト自体には、開発バージョンでのみ満たされる要件があるため、ロックは失敗します。 つまり、1レベル下です。

バージョンを明示的に指定する方法をとった場合、 allow_prereleases = trueときにプレリリースを許可せずに、バージョンを大まかに指定する方法はありますか？

「ゆるく」とは、 ==x.*や>=x.y 、つまり部分的に修正されたバージョンを意味します。

はい、プレリリース以外の場合のみ：

pipenv install 'mydeps>=1.2,<1.3'

== 1.2はすべてのバグ修正バージョン（1.2.1、1.2.2、1.2.3、...）を意味することに同意しますが、npmがこれで持つすべての混乱を望んでいません。

私は再定式化することができます：問題を好転させてallow_prereleases = trueを使用する方法はありますか（一部のパッケージのプレリリースバージョンが必要なため）が、緩い（部分的に固定/制限された）バージョンを使用しながら他のパッケージのプレリリースバージョンを明示的に禁止します仕様？

しかし、それでは、これではサブ依存関係の問題は解決されないことに気づきました。

私には、この問題はかなり重大なようです。 プレリリースバージョンのユーザビリティは各プロジェクトに依存するため、すべての依存関係に対してプレリリースバージョンを許可することは実際には意味がありません。 一部のプロジェクトには非常に安定したプレリリースがありますが、そうでないプロジェクトもあります。プレリリースバージョンを使用すると、アプリが破損します。

グローバルなallow_prerelease = trueを必要とせずに、少なくともピン留めされたバージョンをプレリリースにすることができる実行可能な修正はありませんか？

@gsemetつまり、 ==1.2.*にはプレリリースが含まれますが、 >=1.2,<1.3は含まれませんか？

--preを使用すると、 >=1.2,<1.3はpreversionを検索します。 ほとんどの場合、プレリリースは必要ありません。実際に使用するには、バージョンをフリーズする必要があります。 --preはグローバルです。つまり、すべての依存関係のプレリリースが見つかります。
pipfileのpre構文では、プレリリースを検索するために1つまたは2つのdepを設定でき、それらのみが使用できます。 しかし、私たちはそれを持っています。

ここで説明したpreように、この問題を解決するためにrequires=[...]またはpip_options=[...]パッケージごとのオプションを提案したので、ここで＃3651について言及したいと思います。 ある時点で、メンテナは他のPipenvおよびpipオプションをパッケージごとに利用できるようにすることを考えることができます。

申し訳ありませんが、 allow_prereleases = trueを使用せずにプレリリースバージョンを固定することはできないと思いました。 その場合、問題は私が思っていたほど重大ではありません。

開発パッケージでこれを実行できないのは本当に辛いことです。

pipenvは、現在、 PEP440仕様に含まれているユーザビリティの推奨事項の1つに準拠していないことに注意してください。 具体的には、「デフォルトでは、依存関係解決ツールは、バージョン指定子を満たす最終リリースまたはポストリリースがない場合に、バージョン指定子に対してリモートで利用可能なプレリリースを受け入れる必要があります」

最近、Pipenvを使用して、 locustioを使用していくつかの負荷テストを設定および管理しようとしたときに、これは私を苦しめました。 新しいバージョンのgeventが必要であり、 --pre引数を追加するまで、 pipenv install locustio正常に許可しません

blackはまだ安定したリリースがないため、常に私を悩ませています。

pipenv +黒=💥

@ andrey-semakin参考までに、 black = "==19.10b0"機能します。 もちろん理想的ではありませんが、pipenvは問題なくインストールします。

参考までに、 black = "==19.10b0"機能します。 もちろん理想的ではありませんが、pipenvは問題なくインストールします。

黒を必要とする別の依存関係がある場合、これは機能しないことに注意してください。ただし、pytest-blackやflake8-blackなどの特定のバージョンに固定しません。 その問題のより詳細な説明は、＃3928およびpeterjc / flake8-black＃18にあります。

したがって、このPipfileの場合、プレリリースをグローバルに有効にすることを伴わない回避策はありません。これは、多くのユーザーにとって大きなノーノーです。

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true

[packages]

[dev-packages]
black = "==19.10b0"
pytest-black = "==0.3.8"

@tharradine ha！ 私はそう、そう、そう、言及された成功した回避策のこの正確なシナリオbcで非常に多くの時間を無駄にしました。
私はついに諦め、すべての開発者に黒いものを手動でpipインストールするように強制します。そうしないと、強制的なコミットフックが機能しなくなります:)。

また、envが更新され、この手動のpip依存関係が失われると、常に苦情が寄せられます。
それは終わらないおかしくなります。

私はちょうどそれを吸いましたbc私はパッケージのためにここで助けを得ることが決してないことを知っていました笑。 https://github.com/pausan/cblackです。

2インデントPythonの場合は黒!! ははは、そこには何の愛もありません。

いくつかの合法的なサードパーティパッケージを投稿してくれてうれしいです！

これに関する効果的な回避策や進歩は本当にありませんか？ 開発中に内部で生成されたアーティファクトのプレリリースを使用できるようにしたいのですが、それでもパブリックライブラリのリリースバージョンに依存しています。 この問題が続く間、pipenvがこの（些細で一般的な）ワークフローに適しているかどうかはわかりません。

詩のような他のツールに切り替えるだけで、歴史を考えるとこれがすぐに解決されるという希望はほとんどありません。

ええ、実際、私は詩を試しているところです。

この問題は、最新の2020リリースでも引き続き有効ですか？

私は問題を誤解しているか、依存関係に幸運があるかもしれません。

rc固有のバージョンのパッケージをpipfileに固定しており、allow_prereleases = trueです。

[packages]
<PACKAGE_NAME> = "==0.12.80rc53"

[requires]
python_version = "3.8"

[pipenv]
allow_prereleases = true

この場合、プレリリースバージョンの唯一のパッケージです。

「*」を許可し、そのバージョン識別子に最新のプレリリースを、pipenv環境全体ではなく、パッケージごとのレベルで含めたいという問題はありますか？

あなたの例が示すように、pipenvは常にプレリリースを==バウンドで明示的に固定できると信じています—そしてそれはallow_prereleases = true必要としません。 そのオプションは「プレリリースはどのパッケージでも問題

これは、残念ながら頻繁に発生する興味深い方法で制限されています（たとえば、まだベータ版と見なされているblackオートフォーマッターパッケージを使用）。

• black = "==19.10b0"を設定できますが、たとえばblackが20.08b0を公​​開した場合、 ==境界を変更するまでプルインされません。
• black>=19.10b0 +「プレリリースは大丈夫ですが、このパッケージのためだけです」と言うことはできません。

pre構文は、私の理解が正しければ、「プレリリースは問題ありませんが、このパッケージのみ」のユースケースを許可することを目的としています。

現在、依存関係を解決するためにallow_prereleases = trueを含める必要があり、単一のパッケージがrcとして修正されています。

この場合、私はrcバージョンの、次の要件を持つ別のパッケージ同様に：

Could not find a version that matches `<PACKAGE_NAME> = "==0.12.80rc53",>=0.1.59`

次に、実際に"==0.12.80rc53"がリストされている「試行済み」のリストを取得しますが、それでも依存関係を解決できないと表示されます。

@kristangあなたはあなたのPipfile構文について確信していますか？

[packages]
some-package = "==0.12.80rc53"

正確なバージョン要件がある場合、複合条件を設定することは意味がありません
黒に問題があり、上記の構文を使用するときにallow_prereleasesが不要であることを確認できます

@ bryan5989ええ私はどこかでエラーを起こしました。 私は、多くの紛らわしい問題と内部Pythonフィードからのバージョン管理の中断に混乱したと思います。

それ以来、期待どおりに機能するようになりました。