Working towards self-update

[wolfv]

• this uses the uncompressed release from Github. We could use the compressed one.
• It updates unconditionally. We should check wether pixi is in the "default" location (~/.pixi/bin/pixi) and if not, probably not touch it (externally managed by homebrew or conda etc.). Maybe add a --force option to allow overwriting in other locations.
• The version comparison code is a bit brittle right now but should probably work fine.

[tdejager]

Nice that you are working on this :)!

Like you said in the comment, I've had problems with this in the past where I've used the command to update a brew installed micromamba and it totally messed up the installation.

If we want to include it, I think we could add the check like you said, or maybe add a feature to not compile it in. So put it behind a feature flag.

Wdyt @baszalmstra and @ruben-arts ?

[baszalmstra]

I feel your pain @tdejager , but dont you think @wolfv s solution to not self-update if the executable is in a non-default location "solves" this?

[tdejager]

Well, if you can still force it, then it would still be a risk. That's why I think putting it behind a (maybe default) feature would be nice :) that way the package manager maintainers have the guarantee it will not happen.

[baszalmstra]

Yeah thats a good idea, but it would mean the package managers always have to build from source to disable the feature.

[tdejager]

Which a lot of them do, or have seperate release for it

[ruben-arts]

What is the status of this PR?

[wolfv]

dormant but not dead! :)

[hadim]

• this uses the uncompressed release from Github. We could use the compressed one.
• It updates unconditionally. We should check wether pixi is in the "default" location (~/.pixi/bin/pixi) and if not, probably not touch it (externally managed by homebrew or conda etc.). Maybe add a --force option to allow overwriting in other locations.
• The version comparison code is a bit brittle right now but should probably work fine.

Are you guys ok if I try to wrap up that feature in a separate PR but based on this branch?

I feel your pain @tdejager , but dont you think @wolfv s solution to not self-update if the executable is in a non-default location "solves" this?

On that topic, I feel it's best to add the logic within the code itself by checking the location of the binary (versus behind a feature) so packager folks don't have to know or remember this particular point when building pixi and everything is self-contained. But happy to follow what you guys think is best.

[wolfv]

@hadim if you take over this PR, that would be great! I am pretty busy with rattler-build at the moment so we would highly appreciate your help :)