Dan Helfman

Personally, I think it's fine to "break" the b3vis/borgmatic Docker URL.. ideally with a deprecation notice in place, but even that is a nice-to-have IMO. When this is done I...

Hope that works! I'd be happy to host a separate registry, but I recognize that makes discoverability and installs more difficult.

I just changed the organization package creation settings here: https://github.com/organizations/borgmatic-collective/settings/packages Not sure if you have perms to change those. If not, you should! Anyway, maybe try again at: https://github.com/orgs/borgmatic-collective/packages/container/docker-borgmatic/settings

That makes sense to me!

Except it looks like the current behavior, in which positional patterns arguments need to come first to prevent silent overrides, is kind of the opposite of the "good and preferred"...

That totally sounds like it could work.

An implementation idea for this: In [`wrapper.sh`](https://github.com/futuresimple/helm-secrets/blob/master/wrapper.sh#L70), if the chart name is not a local directory path (`if [ ! -d "$chart" ];`), then you you could assume that the...

It looks like implementing this may actually be much easier after the separate https://github.com/futuresimple/helm-secrets/pull/60 get merged in. That's because the existing wrapper.sh doesn't do any real parameter parsing, so it's...

Our use case is as follows: We've got a private package server, and we're actually packaging up various configuration (including helm-secrets encrypted credentials) *as Helm charts*. (And those charts internally...

I think you're right that it might be a cleaner implementation for the code paths to be separate, although it might be a slightly nicer user experience if a single...