Arch Linux User Repository

Sorry, I was wrong about sudo.
pacman doesn't depend on it, I somehow mixed this up with base-devel group which includes sudo.

1 & 2 Does this pip installation work correctly?

Yup, the code has some logic in place to check whether:

1. It's running in a virtual environment
2. All dependencies are available through the system package manager
3. It's running on Python < 3.11 (before --break-system-packages was enforced)

If 1. is satisfied, then all pip install commands will be run within the venv - no tweaks required.

Otherwise, if 2. is satisfied, then the python-* packages provided by the system package manager will have priority over pip install.

Otherwise (i.e. if some optional dependencies aren't available through e.g. pacman), and 3. is satisfied, it'll run pip install - in the system Python libs if running as root, in the user's home installation folder otherwise.

If running on Python >= 3.11, the application passes --break-system-packages as a workaround.

Then one can argue that this entire package is not needed because users just can install from all with pip.

Not really. The application has some base dependencies, and then many optional dependencies, depending on what plugins the user wants to use.

The dependencies for those plugins can be installed in many ways - the Web UI and the online docs provide both the pacman and pip install commands for each of the extra integrations. Automatic installation via API/UI is only one of the possible ways. It's usually advised only in virtual environments and container installations, and on recent versions of Python it requires pip with the --break-system-packages workaround (and it may break system stuff if the application is run as root), but the method is nevertheless available - although discouraged on system installations.

If by "available package manager" you mean pacman (or aur helper) then it's redundant

this is already taken care by python-redis

Good to know, I'll proceed with removing redis and sudo then.

Package always provides (and conflicts) with self. platypush-git already conflicts platypush so this is not needed in this package.

Dependencies:
1 & 2 Does this pip installation work correctly? (I didn't test fwiw). python package provides python-externally-managed, so pip won't work without some workaround https://peps.python.org/pep-0668/

I don't think sudo in depends is right way. If by "available package manager" you mean pacman (or aur helper) then it's redundant because these tools already depend on sudo, so this is not needed for this pkg per se.

In the case of using pip from is not really right way to do this. This also doesn't make sense, because user should not download into / but use ~/.local for example. Then one can argue that this entire package is not needed because users just can install from all with pip.
3. I see, this is already taken care by python-redis so explicit redis can be removed if you want to get rid of this namcap warning.

please also remove provides and conflicts.

Those are to ensure that platypush and platypush-git can't be installed simultaneosly.

Namcap also complains about these unneeded dependencies

Good catch, some of them were leftovers that I forgot to clean up, but some are required even if not imported/used directly:

1. pip is required to install optional packages through the API/UI
2. sudo is required to install optional packages dependencies via the available package manager by the API/UI
3. redis runs the application bus and Platypush can also be configured to start it directly

Thanks, please also remove provides and conflicts. This is not needed. Namcap also complains about these unneeded dependencies (this is same for -git package btw)

platypush W: Dependency included, but may not be needed ('python-frozendict')
platypush W: Dependency included, but may not be needed ('python-pip')
platypush W: Dependency included, but may not be needed ('python-pytz')
platypush W: Dependency included, but may not be needed ('python-wheel')
platypush W: Dependency included, but may not be needed ('redis')
platypush W: Dependency included, but may not be needed ('sudo')

Additionally these messages about directories/files and missing license

platypush W: Directory (etc/platypush/scripts) is empty
platypush W: Directory (var/lib/platypush) is empty
platypush W: Directory (usr/src/debug/platypush) is empty
platypush E: Uncommon license identifiers such as 'MIT' require license files below /usr/share/licenses/platypush/ or switching to common license identifiers. Found 0/1 required license files.
platypush W: File (etc/platypush/scripts) does not have the world readable bit set.
platypush W: Directory (etc/platypush/scripts) does not have the world executable bit set.
platypush W: File (var/lib/platypush) does not have the world readable bit set.
platypush W: Directory (var/lib/platypush) does not have the world executable bit set.

I didn't check all optdepends since they are so many. I think that's all my nitpicks.

I've just pushed a fixed release - it looks like the CI/CD process for some reason calculated the sha512sum of the previous version of the package...

==> Validating source files with sha512sums...
    v1.1.3.tar.gz ... FAILED
==> ERROR: One or more files did not pass the validity check!