Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pypi support for pixi global subcommands #565

Closed
YeungOnion opened this issue Dec 13, 2023 · 8 comments
Closed

pypi support for pixi global subcommands #565

YeungOnion opened this issue Dec 13, 2023 · 8 comments
Labels
✨ enhancement Feature request

Comments

@YeungOnion
Copy link

Problem description

Pixi is adding support for pypi, and I think pixi global should support it.
I don't think this one part is a big lift, so I'm willing to take it on. But I do have a question to start, because perhaps this could be decided as out of scope.

I believe that each package installed with pixi global install has its own environment, but I may want to be able specify that I want to install packageA in the same env that I installed packageB. Even beyond pypi packages, does pixi global allow for dependencies beyond the conda recipe? (Note that pipx's subcommand inject package [unexposed_dependencies ...] has this behavior and it also does manpages)

A common use case could be

For all my python projects, I'll want a language server and some plugins that connect it to dependencies like black and mypy. I don't use binaries exposed by these dependencies other than my editor starting the lsp, but I'd want the lsp plugins to have those dependencies. I could use pixi at the project level for this, but then I'll have a copy of the language server tools in each project

Should I install the lsp server with plugins and depends with pixi global or should I use something else?

@YeungOnion YeungOnion added the ✨ enhancement Feature request label Dec 13, 2023
@ruben-arts
Copy link
Contributor

He,

The pixi global inject feature request was already requested in: #342.
We agree that this would be an awesome feature but pixi global didn't get a lot of love the last months. We're very open to pull requests. This counts for both the pypi integration into global and the inject. It would be best to split them into two PR's.

It feels to me that the pixi global install --pypi x would be an easier thing to build as the global envs are really bare. They don't have an pixi.toml which would be nice if we start doing an pixi global inject to keep track of the environment.

To your last question, as of right now it might not be the best fit for your use-case. We designed it to be nice for single tools but not really a "base" environment type of solution. Until the inject is solved, you should probably stay with pipx. But you can install pipx using pixi global install pipx 😉

@YeungOnion
Copy link
Author

YeungOnion commented Dec 15, 2023

Since pipx is good at what it does, I think I'll look at working on global inject with a managed pixi.toml, then global inject will have the same behavior as project add once the context is specified and the --pypi flag will also be the same behavior.

@liquidcarbon
Copy link
Contributor

liquidcarbon commented Jan 1, 2024

I'm confused about pixi global.

What I saw

Ran pixi global install python to get my base python. There's no other python on my system as of now.

Then I wanted it to have pip:

pixi global install pip
✔ Installed package pip 23.3.2 pyhd8ed1ab_0 from conda-forge
  These apps are now globally available:
   -  pip
   -  pip3

$ which pip
/home/a/.pixi/bin/pip

So far so good. Then ran pip install requests. Then:

$ python -c 'import requests'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ModuleNotFoundError: No module named 'requests'

Huh?

$ pip show requests
Name: requests
Version: 2.31.0
Summary: Python HTTP for Humans.
Home-page: https://requests.readthedocs.io
Author: Kenneth Reitz
Author-email: me@kennethreitz.org
License: Apache 2.0
Location: /home/a/.pixi/envs/pip/lib/python3.12/site-packages   # <--- why?
Requires: certifi, charset-normalizer, idna, urllib3
Required-by: 

What I intended

python -m ensurepip --upgrade
alias pip='~/.pixi/envs/python/bin/pip3'

or that ~/.pixi/envs/python/bin would be on PATH

Sounds like pixi global install pip maybe should've been sufficient.
What's the right way to think about it?

@ruben-arts
Copy link
Contributor

He @liquidcarbon, pixi global is like pipx as in it generates a virtual environment per package.

This means if you globally install python you'll have a pixi environment with only python installed. Then installing pip globally will make another new environment that only has pip (and python as that is a requirement of pip). So those are two different environments with possibly two different versions of python.
If you then use pip to install pypi packages it will be installed in the pip environment, because that is what pip in conda environments does.

Thus this way of working with pixi global is not really going to work. What might help is that pixi global inject command requested in #342. But we're currently putting focus on the projects.

My advise for now is to use pixi global for stand-alone tools and application and install libraries only in the pixi projects.

@liquidcarbon
Copy link
Contributor

@ruben-arts thanks for explaining, never used pipx, didn't realize that's the model for pixi global!

@matthewfeickert
Copy link
Contributor

It feels to me that the pixi global install --pypi x would be an easier thing to build as the global envs are really bare

This also seems to be a better matching of existing APIs given that pixi add --pypi exists.

$ pixi --version
pixi 0.15.2
$ pixi add --help | tail -n 40
Options:
      --manifest-path <MANIFEST_PATH>
          The path to 'pixi.toml'

      --host
          The specified dependencies are host dependencies. Conflicts with `build` and `pypi`

      --build
          The specified dependencies are build dependencies. Conflicts with `host` and `pypi`

      --pypi
          The specified dependencies are pypi dependencies. Conflicts with `host` and `build`

      --no-lockfile-update
          Don't update lockfile, implies the no-install as well

      --no-install
          Don't install the package to the environment, only add the package to the lock-file

  -p, --platform <PLATFORM>
          The platform(s) for which the dependency should be added

  -f, --feature <FEATURE>
          The feature for which the dependency should be added

  -v, --verbose...
          Increase logging verbosity

  -q, --quiet...
          Decrease logging verbosity

      --color <COLOR>
          Whether the log needs to be colored
          
          [env: PIXI_COLOR=]
          [default: auto]
          [possible values: always, never, auto]

  -h, --help
          Print help (see a summary with '-h')

So strong 👍 for this.

@ruben-arts
Copy link
Contributor

Hey all, we currently don't see a close future where we would be able to do a better job than pipx. So I'll be closing this issue for now.

I know it's nice to have but in the current state we don't want to take on the extra maintainence while there is an other tool we really like and does exactly the same.

You can use pixi to install pipx.

pixi global install pipx
pipx install ruff

Our plan is to make the pixi global experience better for the conda packages. Follow this milestone: https://github.com/prefix-dev/pixi/milestone/9

@apcamargo
Copy link

Out of curiosity, does the new pixi global make it easier to add this functionality in the future? I agree it is easy enough to just install uv, but it would be great to be able to use Pixi for all installation needs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement Feature request
Projects
None yet
Development

No branches or pull requests

5 participants