Juho Mäkinen
Juho Mäkinen
I would expect this to work ``` binaries = ["a", "b"] version "0.0.7" "0.0.8" "0.0.10" "0.0.11" "0.0.15" "0.0.27" { binaries = ["a"] } version "0.0.30" {} ``` But that fails...
This is even if the previously synced private repo contains manifests overwriting the ones in the public repo
If a package was removed from the manifests for some reason, we should still be able to uninstall it from the environment. Now, we are getting a package not found...
We should check that at least some of the `source` references in the new release are available before creating a new release. For example releases 2.7.0 - 3.1.0 in https://github.com/pressly/goose/releases/...
We could have something like `HERMIT_CHANNEL_FREQUENCY_OVERRIDE=15m` to override the sync frequency in CI so that changes would take effect faster, making it easier to roll out fixes in the CI.
We should release a new version of Hermit on a regular schedule (once a week?) if there are unreleased changes.
At the moment, this only gets triggered for new packages when an environment is re-activated
Sometimes the users get their `bin/` stubs in inconsistent state, where there are unlinked `bin/.-.pkg` files. We should detect if this is the case, and either fail or show a...
When a user pulls changes from a remote repo, containing a recently released version of a package, they might get ``` no version ... found in versions ... ``` error....