#54 warning python-supabase/.pacnew/Bundle

[Anonymous]

Originally created by: Pfeifenraucher-WE
Originally owned by: Sanjaya-Danushka

Hi out there,

I started to test your neoarch and I have three issues:

1. As far as I can see it, neoarch seems to suggest a non-existing package "python-supabase":
   $ Authentifizierung erforderlich… $ neoarch setup → python-supabase ✓ Setup finished — re-checking ────────────────────────────────────────── erneut prüfen $ Authentifizierung erforderlich… $ neoarch setup → docker, gnome-keyring, python-httpx, python-supabase ✓ Setup finished — re-checking ────────────────────────────────────────── erneut prüfen $ Authentifizierung erforderlich… $ neoarch setup → python-supabase ✓ Setup finished — re-checking ────────────────────────────────────────── erneut prüfen $ Authentifizierung erforderlich… $ neoarch setup → python-supabase ✓ Setup finished — re-checking ────────────────────────────────────────── erneut prüfen

How do I correct that? There is only a 'supabase-bin' in aur.

1. Viewing .pacnew:
   While selecting one entry to check/apply/delete the changes, I can't see the very last entry. I have to close and re-open Config-Files (.pacnew) and tap on the last entry to check/apply/delete the changes.

2. Bundle seems to be a fine feature, but I'm not able to export my actual packages into a local (server-)path, nor even to select all packages as suggested from home-screen.
   But first I will checkout your docs what's going to fail.

regards

[Anonymous]

• assigned_to: Sanjaya-Danushka

[Anonymous]

Originally posted by: Sanjaya-Danushka

Thanks for the detailed report — all three issues are fixed in the current release (v3.2.0-3):

1. python-supabase loop — python-supabase isn't in the Arch/AUR repos, so setup kept re-offering it in an endless loop. NeoArch now installs it from PyPI through its own Python (pip install supabase), and dependencies that still can't be installed are silently suppressed for the session instead of being re-offered forever. To install it manually: python -m pip install --break-system-packages supabase.

2. Last .pacnew entry hidden — the diff pane is now resizable (list/diff splitter), so no entry is below the fold, and after Accept/Delete the selection moves to an adjacent entry instead of being lost. Works with every item, including the last one, without reopening.

3. Export / Select all — the Home toolbar now has a "Select all / Clear selection" button (works in grid view too), and "Export Bundle" saves to any local or server path you type, appending .json and creating missing directories automatically.

Please update (yay -Sy neoarch or paru -Sy neoarch) and re-test. If anything still misbehaves, tell me which step and I'll dig in.

[Anonymous]

Originally posted by: musqz

Ran into the same python-supabase warning on Mabox (Manjaro/Arch-based) and wanted to flag a problem with the v3.2.0-3 fix described above before it settles as the permanent approach.

python -m pip install --break-system-packages supabase (and, if "its own Python" means literally invoking pip against the system interpreter rather than a separate venv, the automated setup path too) installs into the system Python's user site-packages, which on Arch/Manjaro is exactly what PEP 668's externally-managed guard is there to prevent.

Concretely, this bites on this dependency in particular: NeoArch already depends on python-httpx (pacman-owned, shown as OK in Diagnostics), but supabase-py pins httpx to a narrower range. A --break-system-packages install drops its own httpx copy into ~/.local/lib/python3.x/site-packages, which precedes /usr/lib/python3.x/site-packages on sys.path — so it silently shadows the pacman-managed httpx for every Python program on the machine, not just NeoArch. That copy is unowned by pacman and won't get rebuilt on the next Python minor bump, so it just goes stale and breaks later, quietly.

Suggested fix: give NeoArch's cloud-sync feature a real app-owned virtualenv instead of touching system Python at all:

python -m venv ~/.local/share/neoarch/venv   # no --system-site-packages
~/.local/share/neoarch/venv/bin/pip install supabase

Import supabase from that interpreter in the cloud-sync code. Nothing leaks into or shadows system site-packages, and uninstalling NeoArch is just removing that directory. Same approach would work unchanged on Debian/Fedora derivatives that are adopting PEP 668 too.

(There's no python-supabase in the AUR to depend on instead — the supabase AUR package is the unrelated Go CLI — so a bundled venv is probably the more practical route here rather than waiting on packaging.)

Happy to test a patch against Mabox if useful.

[Anonymous]

Originally posted by: Sanjaya-Danushka

You're right, and thank you for the detailed analysis — I've reworked the fix. pip install --break-system-packages supabase into the running interpreter does drop a supabase-pinned httpx<0.26 into ~/.local/lib, which shadows pacman's python-httpx for the whole user session.

New approach, exactly as you suggested: supabase now lives in an app-owned venv at ~/.local/share/neoarch/venv (created without --system-site-packages), and cloud sync imports it from there. The system interpreter is never touched, pacman-managed packages can't be shadowed, and uninstalling is just removing that directory. python-httpx was also removed from the diagnostics list since it's now a venv-internal dependency. Fixed in latest main / neoarch-git.

If you can, do test the new setup path on Mabox — happy to iterate if anything's off.