Skip to main content ↑ ↓
Topic: python-daemon vanished (Read 486 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

python-daemon vanished

Hi all,

about a year ago, I installed the python-daemon package to work on a Python daemon. I now used my Artix machine again to code on it, and noticed that apparently, this package has been removed, and the installed version also has been uninstalled.

It seems that there's an AUR package for it, but I definitely installed it without using AUR.

What's up with python-daemon? Would be very nice to get it back …

Cheers, Tobias

Re: python-daemon vanished

Reply #1 –
A python-daemonize package is in the repo here

Re: python-daemon vanished

Reply #2 –
Yeah, but that's another package – python-daemonize is not python-daemon …

Re: python-daemon vanished

Reply #3 –
Well I guess pip install python-daemon is the way forward then;  the AUR has 3.0.1-1 and pypi.org has 3.0.1

Re: python-daemon vanished

Reply #4 –
That is unfortunate …

Re: python-daemon vanished

Reply #5 –
It's easier to use the AUR package if it works for long term reliability, from past experience anything installed with pip will be fine until there's a major version update of Python and it forgets what's installed because of a new Python directory name so you have to find and delete the files manually and reinstall, unless that situation has been fixed of course.

Re: python-daemon vanished

Reply #6 –
I agree that a pacman installed version (or AUR) is best because of the possibility that the AUR will get rebuilt. My experience with archlinux hasn't been good though. I don't think there's any way for the pacman process  to make a python update also install all python related packages.  Others complain about this here and here.

I see no generic python hook in /usr/share/libalpm. Perhaps the AUR pkg could provide one that routinely checks when python is installed.

As part of my work I have multiple self compile pythons to test reportlab. Even that can fail if commonly updated C system libraries (eg libmpdec, expat & ffi)  are used.

Node, java and perl also suffer.  :'(

Re: python-daemon vanished

Reply #7 –
Quote from: replabrobin – on
I don't think there's any way for the pacman process  to make a python update also install all python related packages
I don't understand what you mean here ?
If there's a minor python version increase i.e 3.11 > 3.12 then all official python packages get updated as well, or if the maintainers (generally of Arch, which Artix follows) neglect to update & rebuild an official python package then things break until they fix it.
This, in my experience, doesn't happen often.

Where issues can arise is that AUR python packages are more likely to break, depending on how well maintained they are and how you handle aur updates, and may need manually rebuilding as until rebuilt their installed modules will be in /usr/lib/python3.11 and now the new python is looking in /usr/lib/python3.12 for them.

As for the OP's question.
It appears that Arch removed python-daemon from their repo's. Artix generally follows Arch in such things.
I don't see why python-daemon would have been uninstalled automatically though? Unless another installed package has specifically named it in 'conflicts=' or 'replaces='.

Re: python-daemon vanished

Reply #8 –
There's a package to help you with this called rebuild-detector  from the Arch "extra" repo which will tell you when packages need to be rebuilt, it has a Pacman hook and runs when you update. It works with ldd for checking libs, Python, Perl, Ruby and Haskell. You can run it manually too with checkrebuild or checkrebuild -v.
You still have to look at the output and decide if you want to run (aurhelper) -S pkg1 pkg2 etc. to rebuild things, or take some other action like removing an old unused package completely.
 If an AUR package does stop working because of a Python major version update then at least you can uninstall it or rebuild it easily because the location of the files is retained by the Pacman database, but my experience in the past is that the new Pip from the new Python will only operate on things installed from that version. This might be intended in case you have multiple Python versions installed at the same time though, I suppose.

Re: python-daemon vanished

Reply #9 –
Quote from: gripped – on
Quote from: replabrobin – on
I don't think there's any way for the pacman process  to make a python update also install all python related packages
I don't understand what you mean here ?
A pure python package needs no attention for micro python changes. If impure then it needs re-building against the new version. Normally the distro maintainers will do that and take care of the minor version changes as well for all python packages.  Impure AUR packages or pure and minor python version changes need a rebuild, but I don't think pacman can do that; one of the AUR aware installers might be able to, but I don't know of any that do.

An AUR package could provide a hook with target python that implemented its own upgrade process; again I don't know of one that does.

Re: python-daemon vanished

Reply #10 –
Quote
but I don't think pacman can do that
pacman doesn't handle AUR packages?
Quote
An AUR package could provide a hook with target python that implemented its own upgrade process; again I don't know of one that does.
That could be done with hooks but is something you'd have to implement yourself I suspect.
As I've mentioned elsewhere I have hooks which patch and rebuild select packages whenever they get updated.

I'm not entirely sure what you mean by 'pure' & 'impure' ? But's that probably on me ?

I can't remember having issues when python is bumped a micro version but that's not to say it's not possible

Re: python-daemon vanished

Reply #11 –
Pure python package is only python. Impure implies it has an extension which needs to be compiled. If a pure python package has impure dependencies they also need to be rebuilt.

In the last 25 years I can only remember one occasion when a micro change caused me any problem. The preppy package broke when a core python person changed the spelling of a code token SC_GLOBAL_EXPLICT-->SC_GLOBAL_EXPLICIT. It should not have been done as micro changes aren't supposed to change the api. Probably excusable since code generation & ast messing is deep in the python's guts.