search

fishworks / gofish

Keep your fish fresh! :tropical_fish:
https://gofi.sh
Apache License 2.0
811 stars 65 forks source link

Installing as a user, not globally as root for a whole system? (Linux) #150

Open daanzu opened 4 years ago

daanzu commented 4 years ago

Is it possible? (For both gofish itself and its packages)

bacongobbler commented 4 years ago

It is not possible at this time. Gofish was built entirely to be a systems package manager like homebrew/apt/yum.

I’m curious to see how this might be possible... perhaps as a flag on gofish init? Let me know what you think. Prior art from other package managers would also be helpful.

daanzu commented 4 years ago

A flag on gofish init would be perfect. I mostly see it as a nice easy way to install and update the many standalone utilities I always end up stuffing in ~/bin on every server I work on, even if I don't have root.

adamcstephens commented 4 years ago

Using gofish to install standalone utilities was a use case I was interested in as well.

The installer would need to a flag too, since stripping sudo would be desirable in that case.

curl -fsSL https://raw.githubusercontent.com/fishworks/gofish/master/scripts/install.sh \
  | sed -e 's/sudo //' | INSTALL_PREFIX=~/bin bash
adamcstephens commented 4 years ago

It is not possible at this time. Gofish was built entirely to be a systems package manager like homebrew/apt/yum.

I’m curious to see how this might be possible... perhaps as a flag on gofish init? Let me know what you think. Prior art from other package managers would also be helpful.

Maybe a better example would be a programming language? I can install python packages into a system location, or tell pip to use a place in my home directory.

bacongobbler commented 4 years ago

I've been circling back to this idea recently. I'm starting to think this might be better overall to allow packages full write access to the user's home directory. We're changing the ownership of /usr/local/gofish to $USER:$USER anyways. I can't fully recall if there were any other hard reasons why I chose to write this as a systems package manager.

This would be considered a major breaking change, too, as users would have to migrate to the new install path. This is pre-1.0 software, but... Eww

I'll have a look into how feasible this may be to implement for the next release.

bacongobbler commented 4 years ago

Maybe a better example would be a programming language?

It's important to note that package managers for a programming language are an entirely different breed of package manager than an OS package manager, so you can't draw the same conclusions based on what they do compared to an OS package manager.

Sam's blog post "so you want to write a package manager" goes into great detail over what goes into a package manager for programming languages and how they differ from OS package managers.

adamcstephens commented 4 years ago

Thanks for the link. I agree there are major differences, but there aren't a lot of examples on the OS side I could think of that would support installation in user home dirs. Nix would be the closest, but it's not a typical package manager.

Given that gofish is like homebrew, and both install in /usr/local but with $USER ownership, it seemed a logical next step that a user could just use their home dir as an installation target. Obviously homebrew doesn't really support this, but if feasible I'd love to see gofish allow it.

azilber commented 3 years ago

Thanks for the link. I agree there are major differences, but there aren't a lot of examples on the OS side I could think of that would support installation in user home dirs. Nix would be the closest, but it's not a typical package manager.

Given that gofish is like homebrew, and both install in /usr/local but with $USER ownership, it seemed a logical next step that a user could just use their home dir as an installation target. Obviously homebrew doesn't really support this, but if feasible I'd love to see gofish allow it.

Homebrew creates the "linuxbrew" user as a sort of config repository. I like the pip idea and using say a --global flag. I think there are cases for both things, some packages you may want to install locally, some you may want to install globally.

Now, that I think about it, I'm liking the idea of having gofish use a --local flag (https://github.com/fishworks/gofish/pull/186).

If you do say, gofish init --local it can build something like ~/.gofish/live under which it can install bin/, lib/, etc... and add it to the local user's path.

I'm actually planning on coding something like this for gofish.

bacongobbler commented 3 years ago

it can build something like ~/.gofish/live

If we're changing conventions... I'd prefer Gofish follows the XDG base directory convention, where GoFish's configuration should live under ~/.config/gofish, cache data under ~/.cache/gofish, and data files under ~/.local/share/gofish similar to other linux tooling.

The only thing the user would have to set is $GOFISH_BIN, which by default could be set to $HOME/bin as there is no standard convention for user-specific binary files in their $PATH. Hence why I chose /usr/local/bin; that's where most other OS package managers install packages, and most linux distributions (and MacOS) have it in their $PATH by default.

I like the pip idea and using say a --global flag.

That sounds like a good idea. I prefer that over a --local flag as that follows the same convention set by other package managers.

An alternative idea would be to detect if we're root, and if so we assume the user wants to install the packages globally. As in, sudo gofish install helm will install helm in /usr/bin/helm rather than /home/root/bin/helm.