Have a chartmuseum.lua sitting in my default rig that looks like:

...
        {
            os = "darwin",
            arch = "amd64",
            url = "https://s3.amazonaws.com/chartmuseum/release/v" .. version .. "/bin/darwin/amd64/chartmuseum",
            sha256 = "2306cd0c982c158a8d565afb2a3a73391b9c4d1e50cfe33a5e954107c8fff0f8",
            resources = {
                {
                    path = name,
                    installpath = "bin/" .. name,
                    executable = true
                }
            }
...

When installing with

fish install chartmuseum

I get

==> Installing chartmuseum...
Error: chmod /usr/local/Fish/Barrel/chartmuseum/0.5.1/chartmuseum: no such file or directory

Platform: macOS

The manual suggests:

Create the Fish Food

gofish update # make sure we've got a fresh checkout of master
vim $(gofish create foo)

I expected this to create Food/foo.lua and open my editor to that file. Instead, it created Food/foo and opened my editor to a blank file (not Food/foo).

Workaround: I renamed foo to foo.lua and edited that.

the name and path (/usr/local/bin/fish on linux/macOS) conflicts with another tool of the same name: Fish Shell.

Implement a fuzzy search engine to find available fish food for install.

implement a clone of brew outdated.

We need a CI system in place for testing changes as well as compiling and uploading releases to Azure.

This works on linux because of the black magic behind /proc/self, but does not work on Windows because there is no equivalent AFAIK.

==> Installing gofish...
gofish : Error: symlink C:\ProgramData\Fish\Barrel\gofish\0.2.0\windows-amd64\gofish.exe C:\ProgramData\bin\gofish.exe: Cannot create a file when that file already exists.
At line:1 char:62
+ ... hildItem "$env:FISH_DEFAULT_RIG\Food") { gofish install $f.BaseName }
+                                              ~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (Error: symlink ...already exists.:String) [], RemoteException
    + FullyQualifiedErrorId : NativeCommandError

For now, users can re-run the install.ps1 script when they need to upgrade.

change versions from the current release to an older release.

Homebrew has a way of defining "resources" in a formula. e.g. https://github.com/Homebrew/homebrew-core/blob/master/Formula/python.rb#L34-L47

There's also a way to link multiple binaries from a given package into /usr/local/bin e.g. https://github.com/Homebrew/homebrew-core/blob/master/Formula/python.rb#L196-L203

fish should have a way to allow a single fish food to install multiple packages.

Uninstall a particular fish food.

remove unused fish food. A food is considered unused when it is not linked.

For example, packages may want to symlink configuration to etc/, include/ or lib/ inside /usr/local. Fish should be able to support that.

Minikube releases binaries on GitHub for example.

I think it would be nice to have a license field on the fish food file, even if it's optional. Since we're working with binary instead of source, it's entirely possible that a license may be something other than a standard open source license. As a user, it would be nice to be able to discover that before installing something.

Here's the SPDX listing of the common license identifiers. It's what NPM, Dep, and similar tools use in their license fields: https://spdx.org/licenses/

display information about fish's environment

this one:

It's a common practice on Windows to release them as .zip files since tar is not available by default on Windows.

See all installed versions of a specific fish food

display information about a particular flavour of fish food. versions, caveats, etc.

This:

><> ls -l /usr/local/bin | grep helm
helm -> /usr/local/Fish/Barrel/helm/2.8.2/darwin-amd64/helm

Should be this:

><> ls -l /usr/local/bin | grep helm
helm -> ../Fish/Barrel/helm/2.8.2/darwin-amd64/helm

We should implement a linter so that we can verify a fish food has all of its ducks in a row. name, description, homepage, license (#50), version, etc.

This command would be useful for things like cd $(fish rig path github.com/fishworks/fish-food)

Homebrew has run into a problem where you can't even view the formula listing on GitHub. Running ls is even a bad idea. Alternatively, the folks working on rust also use an index on GitHub but found a different structure that's worth looking at. See https://github.com/rust-lang/crates.io-index

create your own fish food for distribution.

Upgrades all fish food installed by fish.

To expedite package creation, it would be ideal to have a homebrew formula transformer for fish food

Opens the homepage of the fish food using the default browser.

Environment

OS: Arch Linux
Kernel: x86_64 Linux 4.15.13-1-ARCH

Something people would recognize, like Visual Studio Code or Helm.

list all installed fish food

Upgrades a particular fish food installed by fish.

GoFish should have a way to declare that one fish food depends (or conflicts) with another.

Gofish cannot be installed (updated) with gofish because of #46.

But gofish also fails to install on Powershell as it refuses to replace gofish binary that already exits!

PS C:\Windows\system32> iex ((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/fishworks/gofish/master/scripts/install.ps1'))
Downloading https://gofi.sh/releases/gofish-v0.4.0-windows-amd64.zip
Preparing to install into C:\ProgramData\bin
Move-Item : Cannot create a file when that file already exists.
At line:23 char:1
+ Move-Item -Path "$tempDir\windows-amd64\gofish.exe" -Destination "$in ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (C:\Users\xxxxxx...md64\gofish.exe:FileInfo) [Move-Item], IOException
    + FullyQualifiedErrorId : MoveFileInfoItemIOError,Microsoft.PowerShell.Commands.MoveItemCommand

gofish installed into C:\ProgramData\bin\gofish.exe
Restart your terminal, then run 'gofish init' to get started!
PS C:\Windows\system32>

Currently gofish upgrade upgrades everything that's installed on the system. It should be smarter and perform some static analysis on what needs upgrading.

Seems like the previous release of minikube is being used instead of fetching the latest release. We should probably namespace the cached downloads to prevent version conflicts when fetching downloads.

==> Upgrading minikube...
Error: shasum verify check failed: checksums differ for /home/bacongobbler/.fish/minikube-linux-amd64: expected '65dcc26a595c73b5bd2a3e47c3d5aa3bbdef81fe603f8d56f947d37cb12c74fc', got '41d666ddc9ea1eee3d08a939b1075347da7e670c93836d2756ee5ef1daaa1457'

The quick fix is to just remove /home/bacongobbler/.fish/minikube-linux-amd64 from the cache before trying again.

Protect a fish food, preventing gofish from installing upgrades

It looks like platform-wise every version of macOS is treated as a single target: darwin amd64.

I know this maps to the model used by the Go programming language, but homebrew clearly distinguishes packages for the different releases of macOS. This will probably start to matter when you define packages that link against system libraries.

Is there a design goal to address this problem?