Missing executables when installing Ansible via pixi global

[jgerster-wetec]

Checks

• [X] I have checked that this issue has not already been reported.

• [X] I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

pixi global install ansible
ansible-playbook

Output:

Command 'ansible-playbook' not found, but can be installed with:

sudo apt install ansible

Issue description

Pixi places only ansible-community executable into ~/.pixi/bin. Other executables located in ~/.pixi/envs/ansible/bin such as ansible, ansible-playbook or ansible-inventory are not added to $PATH.

Expected behavior

All Ansible related executables should be added to $PATH.

[pavelzw]

The ansible and ansible-playbook executables are part of ansible-core (which is a dependency of ansible). pixi global install only places the binaries from the explicitly requested package on PATH. otherwise you would have a lot of python at the same time in PATH. it's not ideal in this case. maybe having something like --include-binary could fix this use case?

[ruben-arts]

@pavelzw do you think it would be possible for the ansible feedstock to re-expose the entrypoints? This way we could avoid extra user input for this use-case?

[pavelzw]

I don't think so... If the ansible-feedstock created these binaries as well, we go into #379 very quickly. The ansible-core feedstock provides the binaries while the ansible feedstock provides all modules that ansible uses. It's also not my decision but the decision of the Ansible maintainer team 😅 The feedstocks just copy what the ansible and ansible-core python packages are doing

[ruben-arts]

Hmm, too bad, hoped it would be possible to forward entry-points. We definitely need a solution for this, but not sure what is the most user friendly one. As needing to specify the --include-binary might be really hard to find/understand and track while upgrading.

[wolfv]

I think I am envisioning that we add "more than one" package explicitly in the global install for ansible, e.g.

pixi global install ansible+ansible-core

Would create an environment where both executables are exposed in the global bin folder - very similar to the inject functionality.

In cases like ansible it would be nice if we could somehow figure this out automatically (maybe with some added metadata in the packages or so?).

[LouisFaure]

@wolfv That would be great! One example I can give is a situation I encountered with Jupyter lab: When installed globally, it is not possible to add any Jupyter plugins as this requires pip, which is missing.

A command like pixi global install jupyterlab+pip would solve that issue

[pavelzw]

This would result in the jupyter-pip being on your global PATH which can lead to a lot of problems.

[LouisFaure]

I do intend to have Jupyter in my PATH for ease of use, however I agree that having pip there is more problematic.

[ruben-arts]

Closing in favor of #342

[dhirschfeld]

Just piping up here with an example I just hit. I installed kubernetes but it didn't expose kubectl... or any binaries:

├── pgcli 4.0.1
|   └─ exec: pgcli
├── kubernetes 1.30.0
├── micromamba 1.5.8
|   └─ exec: micromamba

I believe this is due to the fact that kubernetes is actually a metapackage^1 which installs 3 separate sub-packages:

requirements:
  run:
    - {{ pin_subpackage('kubernetes-client', exact=True) }}
    - {{ pin_subpackage('kubernetes-node', exact=True) }}
    - {{ pin_subpackage('kubernetes-server', exact=True) }}  # [unix]

I can easily workaround it by installing the sub-packages individually, but it was initially surprising until I found this issue.

[wolfv]

Hmm, maybe there is a way to detect this case @dhirschfeld. We could check if the package you install does not contain any binaries, and then expose all binaries of the direct dependencies.

[dhirschfeld]

Hmm, maybe there is a way to detect this case @dhirschfeld. We could check if the package you install does not contain any binaries, and then expose all binaries of the direct dependencies.

I guess you'd want to check if it's a metapackage, then expose the binaries of the direct dependencies.

I'm not sure how easy it is to check if a package is a metapackage or not though. There might be a number of packages which don't have an entry-point but which depend on packages which do. Perhaps if a package contains no files is a better indication that it's a metapackage?

[wolfv]

Yeah, it could work @dhirschfeld - on the other hand it would still fail for the ansible usecase mentioned in the original issue (apparently that does contain one executable).

[dhirschfeld]

Maybe "refuse the temptation to guess" and allow the user to specify the behaviour with a CLI flag.

Maybe --expose-deps to expose binaries from all direct dependencies and --expose-deps 'kubernetes-client,kubernetes-node' to specify which dependencies to expose binaries from?

I guess that's ~similar to what you suggest above (with the addition of the CLI flag).

[wolfv]

We're playing around with a global "manifest" file that would allow to add multiple packages into a "global env" and also to expose multiple binaries from multiple packages.

This configuration would work, for example:

envs:
  ansible:
    dependencies:
      ansible:
      ansible-core:

The PR is ongoing here: #1655

[Hofer-Julian]

The new pixi global in v0.33.0 release automatically exposes executables of the same name as the package. Therefore pixi global install ansible will just work