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
appimagekit: init at 20180727 #44520
Conversation
Failure on x86_64-linux (full log) Attempted: appimagekit Partial log (click to expand)
|
Success on aarch64-linux (full log) Attempted: appimagekit Partial log (click to expand)
|
@GrahamcOfBorg build appimagekit
|
Success on aarch64-linux (full log) Attempted: appimagekit Partial log (click to expand)
|
Failure on x86_64-linux (full log) Attempted: appimagekit Partial log (click to expand)
|
OfBorg timeout on LLVM build, I did build it locally, so let's merge as is.
|
Thanks! I will definitely make use of this in nix-bundle. |
TBH, after playing with nix-bundle (it's pretty awesome, thanks for making it) I think that it should be slurped into nixpkgs. Like wouldn't it be awesome if one could just do |
I think this is definitely an option in the future. The main issue is how slow startup times are. Even small things take up to a second to start up. But I definitely think we can get the times down if we switch
We would have trouble putting the Nix installer in nix-bundle - the chroot will prevent it from working I think. I think the more cross-platform alternative to nix-bundle for these use cases is just to link everything statically.
I actually provide a single executable Nix at https://matthewbauer.us/nix. I use it a lot in places where I don't have sudo. You can build it yourself with this pr: matthewbauer/nix-bundle#35. |
The main issue is how slow startup times are
I think it's good enough already. nix-bundle saved me a couple hours of the usual screwing around trying to properly compile things I need with all the options I want on an impure distro. I'd feel like I'm winning the cost/benefit thing even if it'd had taken a minute to start. (Unless I'd need to start it hundreds of times or something.)
But having an option of caching the unpacked bundle would be nice, I completely agree.
We would have trouble putting the Nix installer in nix-bundle - the chroot will prevent it from working I think.
Assuming non-root pids can manipulate their own VFS namespace I'd expect we can just point /nix to the /nix in the parent's namespace.
I think the more cross-platform alternative to nix-bundle for these use cases is just to link everything statically.
That would work for the nix use case, but I made this in the hope that I would eventually be able to make app binaries I could directly use on other distros. Like, I want to take my emacs together with config and packages to other people's machines sometimes to show them how awesome org-mode is.
"Here is the binary you can run in an Ubuntu VM, here's the .nix expression you can build if you don't want to run my binaries, take it, play with it" is much more convincing than "Here, let me show you how it works on my machine in my hands with piles of magic .el and scripts you're not gonna see."
I actually provide a single executable Nix at https://matthewbauer.us/nix. I use it a lot in places where I don't have sudo. You can build it yourself with this pr: matthewbauer/nix-bundle#35.
Yeah, I saw that. Wouldn't it be nice if nixos.org's nix would be like this too, right? (And screw the old UI :) )
|
Motivation for this change
@matthewbauer mentioned in https://github.com/matthewbauer/nix-bundle/blob/master/appimagetool.nix that he couldn't build it via nix, I thought I'd give it a try myself. Took quite some work, indeed.
Things done
But I feel it's better to contribute this now, as opposed to fermenting this patch in my local branch till I feel like continuing this.