This has been a craw sticker for a hot minute. I’ve tried to ignore it but I can’t.
I am running pip 20.2.4 locally, but discover wants to update pip from 20.1.1-1 to 20.2-1. when i run the update with discover it throws error “conflicting files found BLECH” because the system is already updated.
Obviously, this causes the “update available” dot to remain lit. Is there a way to manually change the version that Discover thinks I have to reflect whats actually on the system? The hope is that by increasing discover above the repo version, it will not try to update pip until 20.2-5.
Discover is not a reliable way to update your system because packagekit(which Discover relies on to perform the updates) doesn’t support any kind of manual intervention which is critical for any Arch-based distro.
You are using sudo pip to manage system packages which is not really appropriate on Arch-based systems because the package manager expects to be the one managing system packages. If you want to use pip for development purposes, don’t use it with sudo and let it keep a local copy of the files. System-wide Python packages should not be managed with pip on an Arch-based distro such as EndeavourOS.
Do you know what you have installed with pip besides pip itself?
I do know whats installed with pip. Only a few packages were manually installed: Keyboard, PIL, are the ones I am using now, and I think PIL was preinstalled. Pip list has every package including wormhole and tensorflow that I know I installed from the AUR. Auto-updating tensorflow is a nightmare keeping up with the code and then maybe cuda might catchup to the requirements.
I came to Endeavor from Mint when I purchased a laptop with updated hardware that Ubuntu hadn’t caught up to. So that’s where my habits come from. Sudo is needed by the keyboard package, and probably Mouse when I get to that stage.
Do I need to rebuild package kit in order for it grab the current version numbers? My main problem is the update notification. The system itself is running great, probably because I keep up with the updates. I am reluctant to remove Discover but if we can replace it with an automated updater then i will not need to look at the little dot.
I understand what you are saying but what you are doing just isn’t going to work.
Updating system python packages from pip will almost always break your updates(as it already has) and will sometimes break your system more substantially if it creates a version mis-match on something critical enough.
There is nothing you can “rebuild” that will force it grab the current version numbers because that is not how package management works. It isn’t looking at the version of the software you have installed. It is looking at the version of the package you have installed. When you used sudo pip to forcibly overwrite the files the package manager has no knowledge of that. You updated the software but not the package so it simply sees that the package you have installed is older than the latest version of the package.
You are either going to need to change the way you manage Python packages or switch to a distribution that isn’t based on Arch.
If by automated you mean unattended, there is no safe and reliable way to do that under Arch-based distros. Updates sometimes need minor user intervention.
However, there are several graphical notifiers/updaters which are more reliable than discover for system packages.
Following your lead, the problem wasn’t Discover or Packagekit. So I decided to “bork or bust” on pip itself.
Future Discovery documentation for this issue.
The fix is:
manually backup “/usr/lib/python3.8/site-packages/pip/”
pip install pip==20.2
then sudo rm -f [the six files listed in the error message] “lazy_wheel.cpython-38.pyc”, “lazy_wheel.py”, “datetime.cpython-38.pyc”, “parallel.cpython-38.pyc”, “parallel.py”, “datetime.py”
then rerun Discover update.
The little dot is gone and pip reports its version at 20.2.
Hi @thom, are you using KDE/Plasma desktop because if you are I may have a solution for you, it is some thing I use myself. In the AUR there is something called the archupdater. In order to install this you will have to install yay which allows you to install applications from the AUR. Don’t worry, it is safe. I hope this helps. Discover is a pain in the ass, remove it, you do not need it.
Cool, any problems give me a shout. I am not the maintainer of the program however, just a user who has found it works well enough for me. It’s not perfect but it’s OK. You need to look at the configuration setup (right click) to make it work how you would like.
The only supported way to install packages on Arch is using pacman. That includes python libraries, node modules, everything… but is, of course, limited to the Arch (and in our case, EndeavourOS) repos.
The other relatively safe way to install programs is through the AUR.
If you must use pip, npm, gem, or any such specialised package managers, only allow them to install stuff in your home directory (which implies never to run them with sudo).
If you are building a program from source code manually, also do it in your home directory and install it there. Anything that is not from the repos or the AUR should be contained in the user space.
My recommendation is not to use Discover at all. It is not installed by default anyway, if you’ve installed EndeavourOS from the latest ISO.
Yeah, I’ve rolled a few versions and this was the first time i’ve had a problem. I thought the problem was discover, turns out I was right, just the fix was to roll back pip manually and then update.
How I got here:
In regards to the installing into home… the “keyboard” package is the issue.
python script:
import keyboard
keyboard.send(‘tab’)
Would press the tab key and requires sudo permissions to hook the keyboard, but “sudo python script.py” throws error that keyboard is not installed, even though its installed in home. So a month after “sudo pip install keyboard” we end up here.
Just one quick obscure package can’t hurt. I use AUR for tensorflow and browsers ect.
With Ubuntu, my code environment was always updated via pip to hide from the system updater that would update and break my code. This hasn’t caused issues before. lesson learned.
It can if it pulls in any dependencies or causes any other python packages to get updated.
I can’t readily explain how much time I have spent helping people who have broken their systems from using sudo pip. Even if it works for a short time it will bite you eventually.
(says with pointy Vulcan ears) Using a distro’s supplied package manager (eg pacman and yay) would appear to be the only logical choice. Live long and prosper.
True. Except yay is not a distro’s supplied package manager. The only supported package manager is pacman.
AUR helpers like yay and trizen are great tools of convenience, because they keep track of installed AUR packages and automate updating them. I use yay all the time, it’s great. However when it comes to the AUR it is expected from the user to do some RTFM and have a basic understanding of what’s going on.
