Installing packags through requirements.txt are not on the path

[mjkl-gh]

I've been trying out the new feature that enable installing python dependencies inside the container. However, something is failing in a weird way.

Some packages seem to be installed on the path others not, specifically httpx, which can be seen in the log:

Installing collected packages: proxmoxer, urllib3, sniffio, h11, certifi, requests, httpcore, anyio, httpx
  WARNING: The script httpx is installed in '/home/semaphore/.local/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed anyio-4.3.0 certifi-2024.2.2 h11-0.14.0 httpcore-1.0.5 httpx-0.27.0 proxmoxer-2.0.1 requests-2.31.0 sniffio-1.3.1 urllib3-2.2.1

This makes any script that depends on this fail unless I add:

      - name: Verify httpx is installed
        delegate_to: localhost
        ansible.builtin.pip:
          name: httpx

Although it is a good practice to ensure installation, regardless where the script is running. This behavior is not what I expected. Especially since other packages do seem to work fine.

[tboerger]

My pending pr for the docker refactoring resolves that problem.

[tboerger]

After #1963 have been merged, could you give that develop container tag another try? I guess this issue should be solved.

[mjkl-gh]

I think watchtower automatically pulled it.

I'm now running into this:

No additional system dependencies to install
Installing additional python dependencies
error: externally-managed-environment
× This environment is externally managed
╰─> 
    The system-wide python installation should be maintained using the system
    package manager (apk) only.
    
    If the package in question is not packaged already (and hence installable via
    "apk add py3-somepackage"), please consider installing it inside a virtual
    environment, e.g.:
    
    python3 -m venv /path/to/venv
    . /path/to/venv/bin/activate
    pip install mypackage
    
    To exit the virtual environment, run:
    
    deactivate
    
    The virtual environment is not deleted, and can be re-entered by re-sourcing
    the activate file.
    
    To automatically manage virtual environments, consider using pipx (from the
    pipx package).
note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

And semaphore no longer starts

[mjkl-gh]

I assume this happens because the pip install --user is called and that has been disabled by the maintainers of alpine, because system packages rely on certain python packages. And running pip upgrade on those might break them

[tboerger]

Looks like I got to add more flags similar to the dockerfile.

[mjkl-gh]

I assume you mean --break-system-packages?

I would advise against as it simply might break the container in unexpected ways, as the flag suggests

I'm currently busy with other things, but maybe I can find some time over the weekend to see if I can create a PR that follows a more distro approved way. Maybe just adding /home/semaphore/.local/bin to the PATH, which was the issue that started this, might be a better solution.

[tboerger]

That's just required because of the restrictions set by alpine devs. The container won't be managed by the alone package manager. Beside that the python deps are only installed in the user space.

[tboerger]

Even if I don't like it, the docker images are using a venev again.