Autojump: 新しいパッケージバージョンでモジュールが見つかりませんエラー

ここmanjaroでも同じです:(
OS：Manjaro 18.1.3 Juhraya
カーネル：x86_64 Linux 5.3.11-1-MANJARO

Manjaroでも同じことがわかりました：

Linux version 5.3.11-1-MANJARO
DISTRIB_ID=ManjaroLinux
DISTRIB_RELEASE=18.1.3
DISTRIB_CODENAME=Juhraya
DISTRIB_DESCRIPTION="Manjaro Linux"

削除を経由して動作を修正autojump使用してyayし、これを用いたクリーンビルドを再インストールします。

これにより、構成ファイルをzsh再調達した後の動作が解決されました。

Manjaro18.1.3もここにあります。 autojumpパッケージを削除して再インストールしてもうまくいきませんでした。 再インストールが失敗しました

==> Error: Could not find all required packages:
    python>=3.8 (Wanted by: autojump)

私のPythonバージョンは確かに3.7.4です。

パッケージautojump-gitは今のところ機能しているようです。

ArchLinuxの自動ジャンプパッケージをAUR経由で管理しています。

• 22.5.3-5には、バージョン管理されたpython依存関係が含まれており、heftegによって提案されたソリューションがFS＃60929に組み込まれています。
• 22.5.3-1には、このサイトパッケージへの移行はありません

モジュールが見つからないというエラーの原因がheftegの修正の実装によるものかどうかを知りたいです。

Archでzshを使用していますが、これは発生しません。 @ tmarti2-

1. makepkgまたはいくつかのAURヘルパー（AURヘルパーを使用しないでください）を使用してビルドしましたか？
2. ~/.zshrcまたはzshファイルに、自動ジャンプ用に何かを参照またはソーシングしているものはありますか？

Manjaroユーザー： Manjaro！= Arch ... @Syphdiasのコメントに基づくと、PythonバージョンはArchのバージョンよりも遅れているため、インストールできません。

PKGBUILDのdepends=と_python=をpython3.7して再構築すると、正常に機能するはずです。

ええ、私はマンジャロの下に​​います、私の悪いです。
Yayを使用していて、.zshrcにautojumpについて言及している行があると確信していますが、何を思い出せません。
明日やってみます。

yayはAURヘルパーだと思います。 それらは解決するよりも多くの問題を引き起こします。 前述のようにPKGBUILDを変更し、 makepkgビルドすると、問題ないと思います...アップストリームに関連していないため、この問題を閉じる可能性があります。

Manjaro18.1.3もここにあります。 autojumpパッケージを削除して再インストールしてもうまくいきませんでした。 再インストールが失敗しました

==> Error: Could not find all required packages:
    python>=3.8 (Wanted by: autojump)

私のPythonバージョンは確かに3.7.4です。

パッケージautojump-gitは今のところ機能しているようです。

Autojump-gitはManjaroでも壊れるようになりました。 アップグレードまたはインストールしないでください。

@ pwoehrer-

Manjaroユーザー：Manjaro！= Arch ... @Syphdiasのコメントに基づくと、PythonバージョンはArchのバージョンよりも遅れているため、インストールできません。 PKGBUILDのdepends =と_python =をpython3.7に変更して再構築すると、正常に機能するはずです。

AURpkgのインストールはすべて間違っています。 必要なモジュールは、.. / lib / python3.8 / site-packagesの外にあるusr / lib / site-packagesフォルダーにインストールされました。

@noelar - /usr/lib/python3.8/site-packages/はこれらの正しい場所です。 参照： https ：

私が間違っている場合は、遠慮なく訂正してください。

Graysky2は正しいです：ライブラリをインストールする場所は確かにsite-packagesディレクトリです。 しかし...

Autojump自体は、python> = 2.6のみを必要とします。 > = 3.8を強制するやむを得ない理由はありますか？

そうでない場合は、次のようにして、システムの正しいPythonバージョンを取得することをお勧めします。

depends=('python>=2.6`)
_python=python${/usr/bin/env python -V | grep -Po '\d+\.\d+'}

これにより、準備セクションでパッケージをいじる必要がなくなり、システムの正しいパスを使用できます。

Pythonバージョンを3.8に強制すると、何らかの理由でPythonの最新バージョンを使用しない、または使用できないすべてのシステム（Archおよび派生物）のパッケージが破損します。 さらに、Archに同梱されているバージョンが再び変更されると、パッケージは壊れます。

免責事項：私はプログラマーでもパッケージメンテナーでもないので、私が言ったことの一部または全部はまったくナンセンスであるか、同じ目標を達成するためのより簡潔またはエレガントな方法があるかもしれません。

私はそのアイデアが好きですが、ビルドマシンがクライアントマシンと同じバージョンのPythonを持っている場合にのみ、それが機能するのであれば。 言い換えれば、3.8（Arch）を搭載したマシンでビルドし、現在のManjaro（3.7）にインストールすることができます。 3.7と3.8の違いがないと仮定すると、追加のディレクトリがあるだけです。

実際に違いがあるかどうか、つまりpython3.8に対してビルドされた自動ジャンプがpython3.7のシステムで機能するかどうかを誰かが確実に知っていますか？

バージョン管理されていない/usr/lib/python/site-packages/受け入れられますか、それとも上記で質問した理由でバージョン管理されていますか？

私は決してPythonの専門家ではないので、正確な問題を理解していない可能性があります。

オートジャンプを見ると、それは純粋なpythonです（まあ、いくつかのシェルフレーバーですが、それは重要ではありません）。 PKGBUILDのコンパイルステートメントは、ライブラリの中間バイトコード（* .pyc）を生成します（バージョンに依存していることはわかっていますが、バージョンが一致しない場合は実行時に破棄されます）。 通常、バイトコードは事前に生成され、書き込み権限を持たないユーザーもスピードアップの恩恵を受けることができます。
とにかくインストールするには書き込み権限が必要であることを考えると、ビルド時ではなく、インストール時にライブラリのバイトコードを生成することは私にとって理にかなっています。

自動ジャンプのPythonソースは、2.6以上である限り、どのバージョンのPythonインタープリターが使用可能であるかを気にしないように記述されています。

しかし、繰り返しになりますが、専門家ではなく、自動ジャンプが好きで、Pythonに手を出すだけです。

ここもマンジャロ、

@ Graysky2が言ったように、

1. wget https://aur.archlinux.org/cgit/aur.git/snapshot/autojump.tar.gz
2. tar -xzvf autojump.tar.gz
3. cd autojump && vim PKGBUILD

# depends=('python>=3.7')
# _python=python3.7
4. replace all the 3.8 to 3.7
5. makepkg
6. sudo pacman -U autojump-22.5.3-5-any.pkg.tar.xz

大丈夫だと思います。

@ pwoehrer-問題は、Pythonのメジャーバージョンリリース（つまり、3.6から3.7または3.7から3.8）に対してこれを再構築する必要があることです。 公式リポジトリにある場合、メンテナはpkgverをぶつけて、 _python変数を変更するだけですが、これはAURなので、バージョン管理されたpython3depで強制する必要があります。

一貫性を維持するためのよりスマートな方法がある場合は、それを私と共有してください。

たとえば、Python v3.7.xに対して自動ジャンプを作成すると、次のようになります。

% pacman -Ql autojump                                                                                       
...
autojump /usr/lib/python3/site-packages/__pycache__/autojump_argparse.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_argparse.cpython-37.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_data.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_data.cpython-37.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_match.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_match.cpython-37.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_utils.cpython-37.opt-1.pyc
autojump /usr/lib/python3/site-packages/__pycache__/autojump_utils.cpython-37.pyc
...

コンパイルされた* .pycがパッケージに含まれている限り、これを実現する方法はありません。 しかし、前に言ったように、それらをパッケージに含める必要は実際にはありません。 それらはシステムのPythonバージョンを使用し、プラットフォームに依存しないため、インストール時に生成することをお勧めします。 * .pcは、ライブラリーが最初に実行されるときに作成されることを意図しています。

また、自動ジャンプが機能するために厳密に必要なわけではありません。ユーザーがsite-packageディレクトリへの書き込み権限を持たないシステムで少しスピードアップするためだけにあります。

だから：いいえ、*。pycをパッケージに含める必要がある場合、これ以上の方法はないと思います。 :-(

このようにしない場合の問題は、 FS＃60929に概説されてい

コンパイル言語で自動ジャンプを実装すれば、この種の問題について心配する必要はありません。 Goで書き直して久しぶりに使っているので、ぜひ試してみてください。 （https://github.com/suzaku/shonenjump）

python3.8をpython3.9にアップグレードするとこの問題が発生するので、python3.8のautojumpパッケージをpython3.9にコピーするだけで、この問題を解決しました。

cp /usr/lib/python3.8/site-packages/autojump* /usr/lib/python3.9/site-packages/

python3.8をpython3.9にアップグレードするとこの問題が発生するので、python3.8のautojumpパッケージをpython3.9にコピーするだけで、この問題を解決しました。

cp /usr/lib/python3.8/site-packages/autojump* /usr/lib/python3.9/site-packages/

私のツールを試してみることができます。 brewで簡単にインストールできます。

@ heppen-メジャーバージョンバンプで他のPythonスクリプトと同じように再構築する必要があります。