Open smutch opened 11 months ago
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 pixi global
to be a wrapper for project-type pixi?
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 envs/my-package
will be the contents of project level .pixi/
directory, env
and prefix
)
... then behave exactly as if using project-type pixi for that project? With some new mappings for subcommands like
global install package
=> init --p $(uname -m)
, add package
, setup ~/.pixi/bin with needed .sh scripts`global inject package depends
=> add depends
, update project for package
if neededDoes that make sense? I imagine once pixi global
manages packages as if they were projects, it'll not diverge from the rest of pixi. The only question would be whether to follow pipx
's approach of, don't global install things that don't have user entry points - I think it's a good approach. Thoughts?
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 global install
as an ordinary pixi
project with added magic of exposing the binaries/entry-points is a good concept that should allow reusing existing functionality.
Things I'd like:
pypi-dependencies
and exposing entry-points from those packages as wellAnother 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 pipx
(that has dependencies I've got via pipx inject
), I'd give them code to run pipx
from their shell.
Is this what we want for pixi
? I think it helps keep the scope down since usage of globals are typically less context-sensitive,
BUT it's not as similar to project TOML's that only support [dev] dependencies and perhaps someone has a need for a more complex globally used tool. Writing it makes me realize I don't think I'd want that. Running from cli seems best I think.
@YeungOnion If I understand your question correctly I think you're correct. We want to keep pixi global
a tat more simple compared to a pixi project. We rather have you share pixi global install x y z
as that is much more simple then sharing configuration files.
Okay, thanks @ruben-arts, I think that's better too. @dhirschfeld maybe postponing exposing binaries from dependencies installed vua inject
.
For now, scope is to only expose binaries that are already exposed with global install
but adding an inject
command for dependencies in those envs. I can do that.
I think implementing
global install
as an ordinarypixi
project with added magic of exposing the binaries/entry-points is a good concept that should allow reusing existing functionality.Things I'd like:
* Allow adding `pypi-dependencies` and exposing entry-points from those packages as well * Allow configuring which binaries / entry-points to expose - i.e. allow specifying entry-points that shouldn't be exposed.
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 pixi run install
task of developing pixi
itself, but if ordinary pixi
projects could expose entry-points globally, it would be really nice for developing tools locally in addition for installing downloaded ones.
pixi global install <package>
then could become a wrapper around pixi init ~/.pixi/envs/<package>
and something like pixi add --manifest-path ~/.pixi/envs/<package> --expose-bins <package>
.
Then pixi global inject <parent_package> <new_package>
would also wrap pixi add --manifest-path ~/.pixi/envs/<parent_package>
and could have --expose-bins
argument as well.
# ~/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 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 .local
version of a config that acts as an override of the regular config file.
Say an pixi.toml
has a dependency that exposes bins.
# ~/xpublish-dev/pixi.toml
[pypi-dependencies]
xpublish_cli = {path = "./xpublish-cli", editable = true, expose_bins = true}
Say, if you run pixi install
(or any other commands that would trigger installation), then it would give a warning, but not expose them automatically.
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 pixi install -expose-bins xpublish_cli
, then they are linked in ~/.pixi/bin/
, and a local config file is created (and added to .gitignore
) to record the users choice.
# ~/xpublish-dev/pixi.local.toml
[pypi-dependencies]
xpublish_cli = {expose_bins = true}
To avoid nagging the user, there could be an --ignore-bins
option as well that would also create a local config file.
# ~/xpublish-dev/pixi.local.toml
[pypi-dependencies]
xpublish_cli = {expose_bins = false}
Do binaries from a project need to be exposed globally?
Wouldn't pixi run <bibary-name>
work just fine?
Just a data point - I tried to use copier
as a pixi global
app but it didn't work as I also need copier_templates_extensions
installed in the same environment.
Thanks @dhirschfeld good one! I think you might be able to do pixi exec -s copier -s copier_template_extensions copier
, (haven't tried it 👼, so ymmv) to work around this for now.
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: