-
Notifications
You must be signed in to change notification settings - Fork 205
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
Pixi global inject #342
Comments
This is a good idea! |
I'd be willing to work on this, would it be right to say if we want to have inject, then we essentially want That is, it'll find the project or init a project in ~/.pixi/envs as a bare pixi project repo (I mean bare as in the content of ... then behave exactly as if using project-type pixi for that project? With some new mappings for subcommands like
Does that make sense? I imagine once |
Mm, from my point of view global environments are indeed slimmed down pixi projects, but without a lot of the complexity of tasks, multiplatform, host/build dependencies and lock files. If you want that you're better of with a project. You can most likely reuse a lot of code but I would not quite treat them the same. |
I think implementing Things I'd like:
|
Another question on a use case is related to sharing the same tools. I haven't had the need to do this, but for example, Someone in my collaboration asks me how I use some tool that I've installed with Is this what we want for |
@YeungOnion If I understand your question correctly I think you're correct. We want to keep |
Okay, thanks @ruben-arts, I think that's better too. @dhirschfeld maybe postponing exposing binaries from dependencies installed vua For now, scope is to only expose binaries that are already exposed with |
I was pondering this today and had the thought, why make it so that only global can expose binaries? I'm taking some inspiration of the
Then # ~/xpublish-dev/pixi.toml
[pypi-dependencies]
xpublish_cli = {path = "./xpublish-cli", editable = true, expose_bins = true} Something like this would also help #1017 for where related subpackages also need to have their entry-points accessible. # ~/.pixi/envs/ansible/pixi.toml
[dependencies]
ansible = {version = "something", expose_bins = true}
ansible-core = {version = "something", expose_bins = true} |
I feel that auto expose into your global space from a project wouldn't fit the pixi project vision. Possibly with a command line addition to allow a user to do it themselves could make sense. |
I was thinking along those lines, but I wanted to avoid the what-ifs in that comment to not confuse the idea too much. A technique that I've seen to deal with this that I've liked is having a Say an # ~/xpublish-dev/pixi.toml
[pypi-dependencies]
xpublish_cli = {path = "./xpublish-cli", editable = true, expose_bins = true} Say, if you run WARN pixi::project: pixi.toml suggested exposing binaries and/or entry points from
`xpublish_cli` to your global environment.
Run `pixi install -expose-bins xpublish_cli` to add to your global environment. If the user decides to run # ~/xpublish-dev/pixi.local.toml
[pypi-dependencies]
xpublish_cli = {expose_bins = true} To avoid nagging the user, there could be an # ~/xpublish-dev/pixi.local.toml
[pypi-dependencies]
xpublish_cli = {expose_bins = false} |
Do binaries from a project need to be exposed globally? Wouldn't |
Just a data point - I tried to use |
Thanks @dhirschfeld good one! I think you might be able to do |
We are currently finishing up a minimal version of the new
Before we release it, we would appreciate it if a couple of users could try it out to make sure we are not missing glaring bugs or UX problems. # Clone the repository
git clone https://github.com/prefix-dev/pixi.git
# Navigate into the repository
cd pixi
# Checkout a specific branch
git switch feature/pixi-global
# Install the Rust project with a custom binary name
pixi run install-as pixid
# Run commands
pixid global install nushell This should work on all operating systems and only requires |
Tried this on windows and got the following error:
The |
Should resolve the issue described in prefix-dev#342 (comment)
Hey Sam 👋🏻 ! Nice find, I opened a PR that should fix this. Could you please check if it solves the problem? |
I get a warning about P.S. Hi Jullian :D |
Also not sure if this is exactly the right place for it, but I just saw the open question in the proposal for "Should we version the manifest?" and I'm just gonna add my 2 cents unprompted: I highly recommend that you do. As someone that has worked a year on things that used to be un-versioned and had to make it versioned, please do your future selves a favor and do it, with a compatibility check if possible. Even a very lightweight versioning like a single number, can save you so much head ache in the future if you ever have to make changes to your format. Of course, it's still all of your decision, but from where I stand the potential benefits outweigh the cost |
oh one other thing that is about this specific PR, the installation and running of tools via this version of pixi go very smoothly but after the command I run exits the terminal immediately closes. I tested this with several versions of Not sure if it is a pixi problem, but I don't remember it happening before, so it might be worth investigating on this side as well. P.S. did some extra testing and this happens in multiple terminal emulators (wezterm which is my daily driver and the built in windows cmd, but not when running powershell) so it might not be pixi after all? I'm really not sure, just leaving it here in case, if I can do more to help diagnose this let me know |
Thanks for the feedback Sam ❤️ |
Problem description
When installing tools using
pixi global install
it is sometimes necessary to install additional packages in the same environment as the tool. For examplepixi global install visidata
will install visidata, but if we want to be able to inspect yaml files then we need pyyaml in the visidata environment too. With pipx, this is achieved usingpipx inject visidata pyyaml
. It would be great to have a similar command forpixi global
.Is there a current method to manually install a package inside a global tool environment? I tried manually activating the environment in ~/.pixi/envs/visidata but when I try using
mamba install pyyaml
I get the following error:The text was updated successfully, but these errors were encountered: