RFC: Handling breaking changes

TL;DR: How should we handle truly breaking changes? With a major version bump or a fork?
Background
gopass has accumulated a lot of features in the past. Some of them were contributed, some never truly finished. Also supporting troublesome dependencies like GnuPG and git adds to the maintenance burden.
It has become clear that we don't have enough time to support all of these feature and dependencies and we prefer to have a stable, polished core feature set over a huge number of partly broken features.
We had some small breaking changes in the last minor release and we will have more small breaking changes while we continue to clean up the code base leading up to a major breaking change in the next major release.
Upcoming Changes
Going forward we consider to:

Drop GPG support, including most tooling we built around that (e.g. key export / import and such)
Drop Git support
Drop most configuration options
Reduce the number of CLI subcommands and command line options
Break compatibility with other pass implementations

This will break most existing setups and will require careful planning and execution.
If you care about any of these features the only (!) way to keep them from being removed are sustained, high quality contributions, e.g. triaging issues, improving documentation, test coverage and finally refactoring the code to make them better maintainable. Unless contributors step up to work on these, the aforementioned features will be dropped. Probably before the end of this year.
Upcoming Changes
While our goal is clear, it's not so clear how we want to get there.
Obviously we want to keep supporting our existing users (but not necessarily on their current stack).
Right now I see two options moving forward.
Both have in common that we will make smaller (possibly) breaking changes in the minor releases leading up to the next major release. We will try to limit the impact but features which are already broken, rarely used or poorly implemented will either be changed or removed.
Also we will work to add support for the storage and crypto backends that will be used in the next major release.
Crypto Backend
In the next major release our age might become our default crypto backend.
I have a very strong preference for age, but this is only possible if the project receives sustained attention and provides answers for some open questions (e.g. Go library support, agent support).
Storage / RCS Backend
While git itself is muss less troublesome to support than GnuPG it still adds unnecessary overhead.
If you think about how we use git you'll realize that we don't need most of it's features, e.g. we don't need merging (useless with encrypted files), branches, tags, or actually almost any other feature it has.
What do we really need in terms of storage / revision control?

a Key-Value stores resembling a file system (tree)
versioned values

Since we can't really merge or diff entries the versioning can just be a list ordered by the revision timestamp. Optionally we'd like to be able to hide the names of the keys (#673, #674).
These properties can trivially be implemented in Go.
Implementation cleanup
It's clear that in the next major release we'll reduce support for different backends, reducing the amount of code.
Eventually we'd like to get rid of complicated recipient key handling. If we're using age the recipient list will already include the whole public key with no need to additionally export or import keys to and from huge keyrings. We might even default to using GitHub username as the default mechanism (age can encrypt for ssh public keys which are publicly visible on GitHub).
Options
This section lists possible options how to reach a major reduction in tech debt with the next major release without loosing most of our users on the way.
Hard Fork
This would be the easiest option.
We would implement all required changes as detailed above in the 1.9 branch and before we start to actually remove features we'd fork the gopass repo to e.g. github.com/gopasspw/gopass2 and keep both repos around: One for the 1.x branch and the other for the 2.x branch.
Obviously we could also do that in the gopass repo with a different branch, but I think that might be more confusing.
However this approach has two big disadvantages:

We'd still have to maintain the old gopass 1.x repo.  For a security critical project this isn't a good idea.
Many users won't make the switch, cf. the Perl5/6 or Python 2/3 situation.

Provide an automated migration path
The second option would be to (try to) automatically migrate all users to the new backends.
This would require us to implement the migration tooling that would automatically migrate the users stores to the new backends in the 1.x branch. If a user misses one of the releases with this migration tooling they would need to resort to the last 1.x release before the can use the 2.x releases.
The big advantage is that this avoid the disadvantages of the first option.
The disadvantage that this is a pretty disruptive change.
Users will need to replace their remote setup (git) with something else (which doesn't exist, yet).
Also they will need to trust a different kind of crypto (which is likely much safer, but in some cases it might be perceived as a step back).
Request for Comments
Please let me know what you think. But please keep in mind that this is an open source project run by volunteers.
Feel free to share this proposal with any gopass users you know.
The question here is not if or when we'll make these breaking changes, only how!
The only way to prevent a feature from being dropped is to make sustained high quality contributions!
Edit: Updated to better reflect to current plans.

I think the gopass --help shows many features that are not important and the features table of the README looks overwhelmingly ambitious (many of which I do not care)
My sympathy for the maintainers because pass and git trade offs hit a sweet spot not found in other programs at the expense of some controversial side effects.
Abandoning GPG sounds so wild and also a huge maintenance burden. I fear for the features I love like: having multiple recipients, an audit trail for my entries, being able to decode using a hardware token on my PC and on on my phone... and foremost, avoiding the tool lock-in because I can always gpg -d my-password.gpg
Even if you go ahead and drop pass compatibility, I think there are two steps due before that decision:

Reduce the feature table of the readme
define-discuss a plugin architecture

By removing GPG and Git support you basically remove the 2 features that made gopass a viable solution in the first place. This move makes absolutely no sense to me. I will probably go with a fork if there is one or fallback to pass and maybe write a small wrapper around it that gives me the 2 or 3 features that gopass has which where the reasons I switched from pass to it. Namely mounts and a better UX.
Sad to see such a good project go away.

Personally, the main feature for me is OTP, GIT, GPG, Teams, and Multi repos. That is why I am using gopass :).
And sadly I really can't help on the code side.

I'll be siding the gentlemen above.
My use-cases really revolve around the smart-cards, in this case Yubikeys. Having a central state-store that allows easy conflict resolution like Git is also essential to me as I'll be pushing and pulling values from different devices asynchronously. OTP is a huge feature as well.
Teams and Multi-repos are features I use daily, but could live with seeing them scaled back for ease of maintenance.
@fgarcia hit it on the nail. Tool agnosticism is and general classic *nix approach is the appeal of this tool. From that perspective, a plugin system makes a lot of sense. It might also be a legitimate way to lessen the maintenance burden of the core of gopass. Focus on a clearly defined API, and provide the bulk of the UX.

Thank you for the sensible comments to this proposal so far.
I'll try to address each concern separately, but first let me try to clarify.

These changes haven't been finalized, yet. First of all this is a (bold) proposal intended to provoke reactions.
There are a lot of features that are not up for discussion, no matter what implementation details we decide on. For example I'm very much committed to: security, ease of use, no vendor lock-in, multiple stores (mounts), remote synchronisation, ...
I'm not opposed to support either GPG or Git, it's just that I don't want to maintain GPG support myself. Personally I don't see any value in GPG over one of the more modern crypto systems and I'm not willing to waste my time on this arcane piece of software. If someone else want's to do that I'd be happy to keep supporting GPG. Otherwise it will go away. That's how open-source works. For git I'm not fully decided, yet. git has a much better track record and is not that much of a problem. It's just that we use only a tiny subset of it's features and some of it's concepts make the implementation a bit annoying. This can be fixed, but I'm not sure if it's the best approach.

@fgarcia Don't worry about either multiple recipients, audit trail or vendor lock in. These are not up for discussion. I'd like to have support for hardware tokens as well, but I'm not so sure if that is a strict requirement. Definitely a nice to have. The feature list, documentation and CLI subcommands are the first things that are being cleaned up right now. This will already help a bit.
I don't think I will invest time into a plugin architecture - that doesn't really fly with Go and a security critical tool. But we're definitely planning to offer a good API to allow using gopass as a library.
@XenGi Git is certainly harder to replace than GPG. But I don't get the point about GPG. If you consider forking already, why not invest the time to contribute to improve the current implementation? We have plenty of issues to get started with.
@nokernel Except for GPG and maybe Git none of these are up for discussion. If we decide to fork the old version would likely bit-rot. I wouldn't have much time to do any more than reviewing PRs - maybe not even that.
@avanier I don't think age is ready just yet. But I bet it might be soon. If it doesn't get some kind of agent and/or hardware token (read: yubikey) support, I won't propose it as an GPG replacement.
Does anyone want to comment why they feel GPG is so important?
I think I get the point about Git and am trying to find a viable way to keep supporting that.
But GPG really feels like a lost cause to me.

My 2 cents about why some people feel strongly about GPG
GpgCard owners (like Yubikey) might feel addicted to the safety of a hardware token that makes impossible stealing a password/keyfile, even if the host system is rooted. Not only that, one just has to memorize a pin code while still getting a really strong key.
GPG and X.500 tends to be the only tool available for Devops people to solve secret distribution, key trust, audit access, signing, revoke keys and allow others to encrypt without a password (asymetrical)

Just to add some of my thoughts here as well. First of all it is crucial to understand that the project is backed by very few people. In fact, if one omits smaller feature contributions and focuses on community moderation (aka. gh issues) and bugfixes, it's almost exclusively @dominikschulz working on the project.
GPG:
Personally, I was mainly involved in the gopass jsonapi and the tightly coupled gopassbridge browser plugin. Just looking at the bug reports for the browser plugin - numerous were directly related to gpg setups or gpg related issues (like agents + gpg hw token stealing focus). As such, interfacing with gpg takes up most of the maintenance time.
Git:
Regarding git, well - here the main point is, that we're not using many of the core features, like branching, merging etc. - we're using it primarily for storing a tree of K/V pairs.
Plugins / Library:
As @dominikschulz mentioned, plugin like systems contradict in many ways the golang single binary philosophy. However, defining a public API that allows using gopass as a library would open the ways to a more maintainable feature set of 'core gopass'.
E.g. Binary Support, HIBP check, Browser API (jsonapi), OTP, YAML support, xkcd password generators and others ... could all be moved out and maintained independently. From my perspective, that would
a) lower the maintenance efforts on gopass side
b) lower the entrance barrier to contribute / maintain a feature for others
As @dominikschulz said, we're still in the discussion (here) on what key points are important for gopass to keep. For me, it's not a specific technology like git or gpg but a feature set. If the same can be achieved with a more maintainable stack, I am more than happy.

These are two examples of how I would imagine an extensible gopass. It would be very easy to offload git and otp related code from the maintainers.
gopass sync
   call ~/pass-store/_bin/sync (bash script)
        git pull
        git push

gopass otp website/example.com
   call ~/pass-store/_bin/otp (bash script)
       otp-generator $(gopass kv --read 'otp' website.example.com)

Once again, I believe extensions and key-value per entry manipulation are the two big missing value/features
But not just inside plugin, also as an outside service plugin. For inspiration you can imagine poor man Vault implementation. The interface is not just the JsonAPI but the CLI too

Adding another 2cents.
Git
Seems like the main concern about git is that you don't use enough of it. I don't really understand that. You use exactly what is needed. For me it's a convenience feature so I don't have to put in the git commands myself and gopass does it automatically. I also don't care if it is git or anything else. I would be totally happy with a hook dir under .config/gopass/hooks/ where I can define commands to push and pull my password-store dir. Then everyone could put in their git, svn, dropbox or whatever calls. Implementing this in a gopass app would be a bit harder. You probably need to put in support for every backend that is needed. But only having git here is probably enough because most other sync backends like dropbox or syncthing do their thing automatically anyways.
 The reason reason I want it in gopass is that it integrates with so much stuff. The main reason is having a pass compatible android app. If gpg support is going away and I think this would be a good thing someone needs to write a gopass compatible android app that works without gpg. I hate android development and I don't have the time to maintain something like that. I would probably fork the current pass app ask a friend to support me with android dev skills and then never touch the app again. This is not an app I would want. So if some android devs could build a gopass app all my concerns would be gone.
The other thing that doesn't concern me but some of my colleagues and friends is the hardware token support. I don't know enough about them but AFAIK they are all bound to gpg. If they can support something else then we could safely remove gpg support and replace it with some sane crypto and all be happy.

@XenGi Thank you. These are all reasonable concerns. We'll try to keep these in mind as we move forward.
To understand my concerns with git (also applies to gpg), please try to understand my situation and goals. I'm maintaining gopass mostly on my own and have very little time besides $work and $family. But I do want to maintain gopass because I like to use it and so do a lot of people I care about. So in order to make this work, I need to reduce the maintenance burder as much as possible. This comes mostly from GnuPG and Git (and some of our past design choices). The problem with git is not that we only use a small part of it, but that the parts we don't need, have to be taken care of as well. Think of workdir vs. index vs. commits and other complications where all we really need is a list of revisions per secret. I'm really undecided about git, let's wait how the alternative experiments turn out.
Hardware tokens are something I'd really like to support (easily). Not necessarily with GPG.
For a mobile app I don't really see the use case (yet). Personally I wouldn't put my secrets on my phone. I'd be curious to better understand your usecases for having gopass on a phone.

Hello all, I am very well familiar with open source maintainership. As such, the gopass team has all my empathy and support for them to do what they find it best for the project and their emotions.
I prefer a well-maintained limited-scope gopass than a kitchen sink, buggy gopass with burned-out or non-responsive maintainers.
To people reclaiming for "their" features, try remember that this is a free and volunteer-based project. We are not in a position to demand anything.
Minor comment about git: personally I don't have a need for git integration, but in case this can help, you might consider https://github.com/go-git/go-git ?
You have all my ❤

I use gopass for so much! Our team at MQS uses gopass together with summon to inject secrets an environment variables directly into our containers so there's no issue with secrets laying around in the open. I love that feature and hope it sticks around.
I use gopass in my personal life as this amazing veneer over pass on the command-line when I'm in a shell. I also use Emacs all the time and really appreciate being able to make use of the underlying pass with Emacs packages like ivy-pass and auth-password-store.
I use the Password Store app on my Android device, which integrates with my GPG key I've added in to another Android app, OpenKeychain, that my Android mail app, K-9 Mail, makes use of to encrypt and decrypt email.
GPG might be arcane but it is ubiquitous! I so love and appreciate being able to step down to the base pass package that powers apps on my phone.

Thank you for that feedback.
Integrations like summon are something we definitely want to keep supporting, we're even trying to make it easier and less cumbersome to maintain these by providing a proper gopass API.
Also the cli surface of gopass should remain (mostly) unchanged, so it should continue to work as a drop-in replacement for pass (wrt. cli).
GPG is another story. It's so annoying ... but it is indeed ubiquitous.
I don't want to keep it. Maybe we end up doing so, but it's not my favourite option.

It's hard to believe you don't see the usecase for a password manager on the phone. I have like a hundred apps on mine and all of them have some kind of account or secret that is all stored in gopass. Also I use a mobile browser and I want to login to the same sites I do on the desktop.
So a mobile app or some kind of integration is an absolute must for me. Since gopass is compatible with pass this is no problem atm because there is a pass app.
About the maintenance. I totally understand that. I also don't want to put too much time in my opensource projects. I can't imagine how hard it must be, having a family and also doing opensource. What about inviting some more people into the project to split the maintenance work? There are clearly a lot of people wanting to use gopass and it being a pretty technical thing I guess some of them are also go devs with some spare time. I could imagine helping myself. I just have no overview where work is needed atm.

I've been thinking about this over the last few days: the "killer feature" of gopass is that it's built over ubiquitous tools. Once you take that away that it becomes another password manager flavor, of which there are dozens if not hundreds of implementations. In fact, if the intention is to move away from the closest thing we have to standards-compliance in the password manager world, would it not be better to put "more wood behind fewer arrows" like @sircmpwn's himitsu?
That of course wouldn't address the then missing Android and iOS apps.

That's also why I use pass. If I just wanted a password manager that is open source and that I can host myself I would have used bitwarden or something similar. The cool thing about pass/gopass is that it is basically gpg+ssh+git+magic. That magic could totally be a simple shell script gluing everything together. Classic *NIX philosophy.

To echo what has been said in other comments:
I use gopass because it provided nice features on top of the feature list provided by zx2c4/password-store, such as mounts, native OTP support, and nicer Git integration. I used zx2c4/password-store because I want my PGP used to encrypt and decrypt my secrets, just like I use it to manage authentication subkeys for SSH-based access, and just like I use it to encrypt sensitive content or messages where necessary.
Personally, removing or demoting support for GPG and Git makes this project unviable for me, and would cause a hard fork in the community. I would be extremely happy to help alleviate the maintainence burden here; I will admit that I have had limited time outside of $WORK and $LIFE but will find a way to make it work if this is the only way to keep these features supported as first-class citizens in the project. Let me know if it would make more sense to talk offline about specific pain points and ways you're looking for help.

I am not completely opposed to these changes, however, like others, above I use the the Password Store android app. I have things that I need to log in to on my phone, so would like to be able to access my password manager from my phone. Note that my phone is encrpyted, and protected by a password. And that my gpg key is also password protected, and I only unlock it when I need access to my password manager. If there was a decent app that supported whatever crypto gopass used, I'd be good with that. But unfortunately, I have very little experience with android development, and what I do have is probably way out of date. I don't think I could build and maintain such an app myself. I would be willing to help contribute to it, if someone else took the lead though.
Another nice thing about using gpg  is that it's easy to have a gpg agent authenticate using your login credentials with pam on linux. One way you could get something similar is if you used the SecretService DBus api (or the mac keyring, not sure if there is an equivalent for windows) to get the private key.

Hi, with my view on things here I want to show appreciation for the great work and the hope that we can find a way to keep gopass up and alive as the great thing it is !
I use gopass mainly as a summon provider across platforms and to manage  secrets within our distributed development teams. My MLF (most lovable features) are the  use of standard tools, the distribution & multi-recipient capabilities and the compatibility with pass ecosystem.

Does anyone want to comment why they feel GPG is so important?

The agent support and the existing (GUI) key management solutions. Although awkward, they exist. An ecosystem around age needs to be build first. For some use case I see age as superior to the GPG (as far as I understand), but with dropping gpg completely we loose many tools that help with managing gpg keys.

I think I get the point about Git and am trying to find a viable way to keep supporting that.

Although I love and use git for distributing the secrets I'm not so bound to have this integrated into gopass. the hook-integration  would be fully sufficient for me. And it follows more the unix tool concept. So if gopass keeps "the possibility"  to use git for distribution it would be OK to remove it.

Wow, I almost missed this RFC!
I don't have much to add to the debate, but from what I can tell and from what I have touched in Gopass codebase, IMO the big problem with PGP is that it is relying on the GPG CLI app, which is a pain since it's heavily system-dependent.
It would be nice to implement #1405 and have a full Go native app (which means replacing Git also with a Go library), but then I'm not sure how the hardware support would work. (From the comment on https://golang.org/src/crypto/rsa/rsa.go#L108 I'd say it might work with hardware modules, but I am yet to find an implementation using it.)
Now, why should we keep PGP?

Compatibility with pass, which could be a big factor to gain new users: people discover pass, meet its limitations and stumble on Gopass that allows for an easy migration path and to keep the same workflow.
Hardware support is a must and is available for so many smartcards and hardware tokens for PGP.
No matter what people will tell you, PGP as we use it is basically just an hybrid encryption scheme and will be secure as long as the primitives are secure. PGP as it is used by email clients, or whatsoever can be frail, but using PGP to just encrypt local files is fine. PGP might not be the most beloved thing in the cryptography community, but it does get the job done.
If I'm on a device without Go, I can still get my password as a .gpg file and use gpg to decrypt it using my hardware token. No need to install Gopass! This is super useful when using an air-gapped machine or a live-CD distro where I don't need to install anything and yet can decrypt my passwords if I want to. I love this freedom.

On my side I would not use Gopass if it didn't support hardware tokens. I know that hardware token support is coming to age through its plugin system and/or through the ssh-agent, and I'm looking forward to it, but it doesn't seem to be quite there yet, although I haven't dug into it too much.
I don't want "yet another keepass" which is basically a black-box handling my passwords, I love the "file-centric", "git-backed", "PGP-compatible" Gopass where my passwords are PGP encrypted files that I can backup using git, Boxcryptor, DropBox, Google Drive, Mega or whatsoever, and decrypt using PGP on any device that has PGP.
(Okay, granted, the git history thing becomes a bit useless past a certain date if you're using a PGP key with an expiry date set in 1 year as I do, but still.) (And yes, Keepass has a CLI that can work with dmenu or Rofi, so the CLI argument is not enough to sell me a Gopass without GPG and Git.)
Now, I do agree that Gopass might profit from a feature removal, or from a clean-up. And cutting PGP and Git would be a good way to refactor and clean-up without it being too painful. But I'm sure we could also go through the whole codebase and find other ways to optimize it, removing some features or simplifying the design without resorting to such extreme measures.
And don't get me wrong: I love age and what they are doing, I hope it will take over and I'd be glad to have both support for GPG and Age within Gopass.
On my side I'd be happy to help more with Gopass, and I will try and look at the issues and contribute more. Or otherwise don't hesitate to tag me on anything encryption related, or easy stuff that you don't have time for :)

Thanks for all the constructive feedback. The goal of this issue was to provide a clear vision of where I'd like to see this project move. Not something that will happen over night.
Of course age isn't ready, yet. Maybe it never will. But it's looking very promising. Promising enough that I'm betting a lot of hours (of my time) on it. Not more, but also not less.
I agree with the hardware token part. It's a must for me as well (but again: with PGP it's just terrible, IMHO).
Also I'm completely sold on the not-a-blackbox part. This is not a commercial product. I don't want to have any lock in effect. People need to be able to access their secrets even without gopass. But that doesn't mean this has to be super easy. However I'm strongly considering to move to a backend that somehow encrypts the secret names, as this can easily leak information (a prototype exists with the ondisk backend).
Currently I'm working on removing as many maintenance burdens as possible (i.e. features which are broken or too toilsome) without breaking (too many) existing use cases. Also I'm continuing to prototype possible implementations for a gopass without either GPG or git as well as designing and implementing a possible migration path.
I'm still very much in favor of dropping support for both GPG and git, but as I've said before: This is not set in stone and I have no idea when this might happen.
Any contributions to clean up the code base, fix or remove broken features or at least document the current features (e.g. how different command line flags should interact) are always very much appreciated.

For a mobile app I don't really see the use case (yet). Personally I wouldn't put my secrets on my phone. I'd be curious to better understand your usecases for having gopass on a phone.

To somewhat add to what has been said: I don't use a password manager for the two important passwords at work. I can memorize those. I use it so that I can have strong, different passwords for each and every service I am signed up to. The fact that the world these days is more mobile than desktop should be well-known. A password manager which I cannot somehow make work on my phone would be 100% useless to me and an immediate reason to switch. It's already bothersome that with Android Store I can only have a single repository cloned, but one is better than none.

Since I'm here, I'd also like to say that I fully understand the rationale for dropping git given how little of it is being used. I'd like to pitch the idea of designing the new version in a way that maybe allows for hooks or plugins. If gopass only writes to some directory and exposes hooks, that plugin could take care of synchronizing the repository¹.
Speaking for myself the main reason I value the git support isn't merging or whatever either; it's that I set up a remote and just have an automatic sync (or only type gopass sync) rather than having to go into a directory, adding, committing and pushing any changes myself. If some external tool can take over that responsibility it would be fine with me.
¹ I know that this could even be done without hooks, but it would still be nicer if such external tools could interface with gopass in some way.

Since what I see as overwhelming opposition to this transition has not swayed the project's leader (evidenced by the prerelease builds), is there someone who is up for maintaining a "classic" fork? I'd have time enough available to triage issues but not much more.

@worldofgeese Did you actually try the PRs? They contain almost no breaking changes. At least nothing that touches the proposals discussed here. I'm still using gopass with gpg and git myself as I did ever since.
I don't see this thread as "overwhelming opposition", but instead as very valueable input, e.g. I still don't understand why you'd want your passwords on your phone, but I see that we need to figure out a way to enable that. My opinion on git has slightly changed. I still think we need to simplify the implementation, but maybe we should keep it. Just because it's so convenient. For gpg on the other hand not much has changed. If age gets proper hardware token support I wouldn't hesitate to drop gpg any moment.

I still don't understand why you'd want your passwords on your phone

I want my passwords on my phone because, at times, I need to enter passwords into applications. Reading a 64-128 character password off of one device (e.g. my workstation) and manually typing it in on another (e.g. my phone) is error prone and not feasible.

My opinion on git has slightly changed. I still think we need to simplify the implementation...

I mentioned this in an earlier comment, as did @marco-m -- what challenges do you see in using either of:

https://github.com/libgit2/git2go
https://github.com/go-git/go-git

I still don't understand why you'd want your passwords on your phone

Just curious, and I realize you said you see now it should be possible in some way, but why don't you think it's very common for people to log into a lot of different services on their phones? What would you recommend to do instead for these users? Maybe this is just an educational issue.

My opinion on git has slightly changed. I still think we need to simplify the implementation, but maybe we should keep it.

That is great news, and I appreciate your reflection on thinking about that. From my personal point of view git is just a really nice, convenient backup feature and if much of the git complexity wasn't supported (and left to the user to resolve outside of gopass should it raise issues) this would be totally fine for me as a user (much like a plug-in / hook architecture would be as well).

@sudoforge Unfortunately both of these libararies don't work for us. git2go is a binding to a C library. But we can't use CGO without massively changing the release workflow. I don't think this would work with cross compiling to Windows. Not sure about the others. And I can't maintain a compile farm for building on all target platform. I did try go-git but it doesn't have merge support. And without that no realistic workflow is possible. It just wouldn't work for any team setup.
@Airblader We have discussed the mobile use case and in my personal experience whenever I set up a new phone there are usually very little apps that require me to enter a long password. But of course everyone has a different workflow.
The git implementation will definitely become a lot simpler. I was thinking of a rather brute force approach (e.g. always running git reset --hard HEAD before writing).

Notice that one of the really nice "feature" of using GPG and git and the same kind of file structure as pass is that it makes Gopass compatible with the "Password Store" app which is itself compatible with the OpenKeychain app to use hardware tokens on Android.
Notice that significantly changing Gopass might also impact other people relying on the somewhat pass retro-compatibility that we currently have. (For instance Password-Store is discussing supporting multiple stores because of Gopass)

there are usually very little apps

Apps often use sign-in through other services, yes, but there's usually a lot of websites for me to sign into at least.
Thanks for the Slack invitation! I'm currently recovering from a hospital visit but will try to join soon and be happy to discuss this further.

#1530 adds a workaround if you rely on the main secret being in the first line of the secret.
It's somewhat of a hack, but it should work for users need this for mobile apps or interop.

@Airblader said:

Apps often use sign-in through other services ...

To add to this -- even if an application offers OAuth sign-in, I (and I'm sure others, as well) may not choose to use it. A good example is when an application's OAuth integration requires permissions which I see as excessive, e.g. access to my contacts or other properties of my IdP profile.

I'd like to echo the comments about GPG + OpenKeychain + Ubikey support. It's very convenient and something that I would like to keep using. Android app is also extremely important for me.
I'd have to revert to GNU Pass if you decide to go forward with changing the implemenation.

I also have a thing or two to say in favor of keep using GnuPG & Git support:
GnuPG
Although we all hate it, please note the fact that some of it's features are irreplaceable. I'm talking about the agent and the pinentry.
The pinentry is configurable from the bottom up: You can choose what pinentry flavor to use with pinentry-program and you can even let it act differently in different environments (using PINENTRY_USER_DATA). Example usages - 1 & 2.
Similarly, the cache timeout being configurable using default-cache-ttl 7200 is also irreplaceable.
Think how wonderful it is that all of these components - the browser, the agent and the gopass CLI play together (if only setup right).
Technically, if you'd implement these features I wouldn't complain. But please consider how tightly GnuPG is audited due to it being widely used. This argument proves the Unix philosophy is relevant once again, and that's the foundation upon the original passwordstore is implemented, righteously.
Git
I'm not sure I understand what's the downside of using Git but not using all of it's features. I guess I do understand that you just want to break free so I'm not left much to say. But once again:
In a way, Git has merging capabilities I doubt you'd be able to replicate. Perhaps not the most sophisticated algorithms are needed for gopass' purposes, but isn't it more then good? It seems to me you are "breaking free" at the price of the whole sync feature.
Perhaps you should consider using a libgit? However, I don't see how that would be less of a maintainence burden.
My personal suggestions
I don't know what will come up at the end of this discussion or at the 2.0.0 release - whether there will be a hard fork etc. But in the meantime, feel free to cc me in any issues related to GnuPG. I consider myself an expert now after this.

@doronbehar Thank you for your feedback. As previously noted, maybe all of this will never happen.
The purpose of this issues was to dicuss the "what-if" scenario.
I'm still not fully sold on keeping gpg. It definitely has some very nice advantages and is widely used, but interfacing programmatically is just so annoying and the myriad of configuration options makes it hard to support this. But I agree that we will need (a) some kind of agent support (for credential caching), (b) hardware token support and (c) mobile apps. We had (a) in gopass, but it was very naive/bad/insecure so I removed it. Unless we can implement all of this we won't remove gpg from gopass.
For git I have less technical concerns, but it feels a bit pointless of having to deal with merge conflicts et.al. when all we need are time-based revisions. We don't even need any kind of merging or conflict resolution. If two secrets are modified at exactly the same time we could just keep both revisions. The main reason why we'll likely keep supporting git is the remote end. Setting up and running a binary (or configuring a GCS/S3 storage bucket) is likely a major hurdle for most people. On the other hand most gopass users have an easy way of creating git repos already. So it's quite likely that we'll keep git either way.
I'm definitely happy to CC you on any gpg related issues. All I want is a maintainable project, and if we reach that goal by getting more people involved that'd be great!

I'm definitely happy to CC you on any gpg related issues. All I want is a maintainable project, and if we reach that goal by getting more people involved that'd be great!

Great :) I was thinking, for GnuPG's issues, perhaps we should highlight in issues' templates that certain common issues are likely to be caused by a faulty gpg-agent setup. Perhaps a link to Arch Wiki's GnuPG's "Troubleshooting" section or a like would be proper there.
I also have an idea that might improve the UX of gpg-agent's issues: When gopass fails to decrypt a password - when stderr of a gpg --decrypt is:
gpg: decryption failed: No secret key
Decryption failed: exit status 2

It might be nice to tell the user to check their gpg setup and use exclamation marks to indicate that the error is likely due to gpg's setup and not gopass itself.

I admit, I only read around 40% of this discussion.
My immediate idea would be this:
Why not join forces? I use @restic. Restic has a 'git-like' functioning, audited encryption and foremost a stable developer community. I think gopass would be a really cool sibling for that project - offloading git and encryption to restic.
(Personally I think we should see a lot more cooperation between large open-source projects)

first: thanks for this great project, the perfect path from just pass
I switched from pass because of gpg-mutiuser-foo and git as various others before. I'd +1 moving everything cumbersome to an external plugin that it is out of your way but still can be used by whomever might depend on it.
Using restic as a backend-plugin sounds like a nice idea @euh2

I totally agree, the code base growth a lot. Some parts are really hard to maintain (I just remember the different URI handling...) and needs at some point aggressive refactor.
@dominikschulz If i understood you correct, maintenance is basically the reason to remove functionality like git and gpg? I see the point to remove those. I am not a fan of calling other CLIs, always feels like workarounds and it can break pretty easy.
Just adding my 2 cent ;-)
Git
Personally i can live without direct git integration. Having some kind of script hook system would be enough for most use cases.
Interesting that this feature tends to survive while most people just need an alternative way to trigger their git syncs...
GPG
At first glance loosing gpg encryption feels hard, as the origin of gopass is a handy and feature rich alternative for pass which promised compatibility. I understand that most people have problems with that. GPG is broad supported across systems, well standardized and bullet proofed.
I also did a quick lookup on age. Interesting concept, but still in early state. I am not a crypto expert, but i am missing some kind of audit to be proofed to be secure and "support" reliability (which means proper RFC, multiple language integration, etc..).
However, as the discussions around gpg is getting personal and opinionated, i am missing hard facts. Can we have a separate RFC or ADR on that? What do we actually need to support? What is the goal? What are the reasons? Which alternatives exists? etc.. Maybe it turns out there is no real alternative and it needs to keep?
Maybe we can also find a way to support multiple (encryption) backends with some kind of extension/plugin system.

@Project0 Thanks for your feedback.
This discussion has become quite long and sometimes emotional.
 That is not true. I was only trying to provide an outlook on what will happen if we don't get these into shape. age isn't fully ready for our usecase, yet. The point I was trying to make with age was that there are viable options to move away from gpg if we choose to.
We're currently doing some requirements engineering (see the docs/ folder) and try to define our core use cases. This is still very early, but I plan to write down all core use cases (aka critical user journeys) over time. This will include the encryption part.
We should have done this before we started writing code, but we didn't. So I intent to fix this in the near term.
Multiple encryption backends, including age, are already supported. But this is another area where we could use better docs.

Since this discussion has mostly focused on (in my view) key features of gopass, namely git and gpg support: what about the rest? @dominikschulz also mentioned dropping parts of the config or unused CLI options. Would it be viable to start a poll with the community to figure out which features are more or less popular (e.g. pass compatibility, mounts, gpg backend, multiple recipients, library/API/3rd party integrations, OTP, rcs/git)? I find it always hard as an open source maintainer to guess which features of "my" software/project are acutally used and which can be safely deprecated. Maybe dropping unpopular features frees some time for widely used features.
In any ways, thanks everyone involved! I really like gopass for its simplicity and ease of use / integration with other standard tools. Kudos for making this possible :-)

@rbott I'd certainly love to get more feedback from our users but this is hard to get right.
I don't want to bother users running gopass and we definitely won't collect telemetry or anything.
We had some good discussions in different github issues already and have adopted accordingly, e.g. I wanted to kill OTP until I was persuaded to keep it. Simliar for git.
If you have any good ideas how to run a good user survey let me know.

I use / want / need from gopass:

Git & Android's app compatibility because I need my passwords on the go.
GnuPG's pinentry and gpg-agent - their integration with the OS and how battle tested are they is an irreplaceable feature.
Browser integration.
OTP - I have many website logins that need otp and having all of them available from the browser is wonderful.

I don't use:

Templates.
Recipients, though I imagine it may be useful for some people, working on a project together.
sum / sha / sha256.
audit - All of my passwords were either created by gopass so they should be very strong, or they were inserted manually and are not strong, due to the website's request to keep the password simple (yes, there are such websites out there).
find - I use my own fzf based script or completion.
fsck - not sure what it does..

Also use Gopass on my Android device with Git and GPG.

Stealing @doronbehar's template so I can put in my 2 cents:

Git integration: a nice to have, for me. I prefer to commit, push myself though
pinentry, gpg and gpg-agent integration: super important,  I used pass, and by extension this project, because this feature allowed me to track my passwords in a VCS system, allowing me to track the entire history of every password I have. Removing this would kill the project for me and send me back to pass.
browser integration: a very nice to have feature, but I suppose I could find some workarounds
templates: I don't use these, but I would if I could find any documentation on it.
recipients: I don't use this feature, but I would plan to in the future, and isn't it tied directly into gpg support anyway?
audit: never used this, don't really care to have it
find: the main reason I switched to gopass was that finding passwords in pass was just tedious, though I could work around not having it
fsck: don't know what it does, don't use it

Dropping GPG and Git support Drops this project.  The point was to make a better more agle version of pass..  bye.

@snuffop Yeah, that's what we've been discussing in this "RFC" as in "Request for comments" and the comments made clear that we should not drop GPG and Git support.

Hello :)
Gopass is intensively used either for personal stuff either within my company :)
We are mainly using GPG + GIT in order to have several teams sharing the same password store ! (dozens of teams)
Don't know if a random comment can help you take your decision but this are the main features that make us using gopass !
Have a great day, and thanks again for the time you spent on it !

I would definitely not continue using the project if GPG and git support was dropped. In fact, I am currently intending to rollback to an earlier version due to the new password format introduced. It broke, for example, compatibility with https://github.com/docker/docker-credential-helpers for me, not to mention pretty much all my scripts in general (due to CLI interface changes) - I would not expect such changes without a major bump.

@rvolosatovs You should be able to disable that by setting the mime setting to false.
And don't hesitate to open an issue with your issues so that we get a user story and can be sure we didn't break things in ways we didn't expect.

You should be able to disable that by setting the mime setting to false.

Per the commit message, GOPASS_DISABLE_MIME "is a temporary workaround and will eventually be removed". (See dca860e)
Additionally, given the swarm of recent changes, it is fairly obvious that this project is plowing ahead with moving away from Git and GPG as defaults.
I wholeheartedly understand the pain points that have been brought up with those particular integrations, but it seems like the feedback given here and the various comments asking for more pointed issues related to those integrations so that we (the users) can help relieve that burden have largely been ignored.
There have been a ton of regressions over the past few months, which I have opened issues for (when I discover the ones that pertain to my workflow), but I can't keep up with it every day -- I have my own commitments. I need my password manager to be stable, and this project seemingly disagrees with that concept.
I am currently using a pre-1.9.1 hash of this project and have no intention of updating. I will be building my own password manager that performs the minimal functions I need. In time, I will open source it.
I'm sad to see that this thread did not command a higher impact on the project's future.

@sudoforge I am planning to do the same for a while. Let me know if you would be interested in working on this together

I'll reach out today.

Additionally, given the swarm of recent changes, it is fairly obvious that this project is plowing ahead with moving away from Git and GPG as defaults.

@sudoforge I think you've misunderstood our goals: we plan to keep Git and GPG for the next few years at least (at least I plan to maintain them as long as I can). There are no alternatives that has the maturity of GPG from a crypto/hardware token/agent point of view, and git is a core feature if you ask me.
The regressions came from the aggressive refactoring with very little code review because there are very few maintainers working on the project, but we have recently tried to change this (sadly after having shipped a buggy v1.10.1).
We also need more regression tests and more tests in general, but before writing such tests we needed to try and define our user stories and the expected behaviour of each cmd. This has been mostly done in https://github.com/gopasspw/gopass/issues/1488 and just requires some refinement for certain commands (templates, e.g.).
I agree we could have done a major version bump before starting to refactor and remove the unused features and all, but too late I guess.

the various comments asking for more pointed issues related to those integrations so that we (the users) can help relieve that burden have largely been ignored.

This is not the case, it's just it takes time to work on all of this, and since there are no urgency to work on GPG and git, we have not yet started doing more than thinking about it, like for example changing from using the git binary to a go git library, and so on. Expect more pointed issues to pop in the coming months, I'd say.
BTW, I think we would love having more people helping with maintaining Gopass rather than creating new password managers.
If something is not working with Gopass or if you'd prefer something being done differently, just open an issue. The more issues we have, the happier we are since it's really difficult to get user feedback, plus it allows us to better understand the different usecases people have for Gopass.

Thanks @AnomalRoil I couldn't have written it any better. I think this issue has been mostly working as intended in raising peoples attention and also in shaping my understanding of our core use cases. In the beginning I had a much more drastic stance on dropping GPG and Git, but a lot of reasonable and justified comments have shown me that these are much more important than I at first thought.
 Although I'll try to work on alternatives.
@daraul Thank you for that concise feedback. Appreciated. Helps us prioritize.
@rvolosatovs Feel free to open a separate issue to track your problems with this integration, if you want.
@insolite Thank you, this is very valueable feedback. We'd love to hear more about your use cases and experience using gopass in a larger team, if you're able to share them.
@sudoforge You are right in that we had some regressions. This certainly wasn't intended. I think @AnomalRoil explained the reasons for that very well. When this project was started myself and a few others (who don't always show up in the commit history) put a lot of time into this project. Then circumstances changed and it didn't get a lot of attention for a while. When I was able to ramp up my contributions again we had a somewhat big and ugly codebase that made it very hard to fix even trivial bugs. I tried to radically simplify things in order to keep this project maintainable. In some cases I did not anticipate the impact some of the changes would have (e.g. the secrets format), it wasn't caught during code review (which doesn't always happen - unfortunately) or testing pre-release versions (not sure if anyone else is doing that).   Feel free to build your own password manager if you want to. I don't mind. Maybe it becomes better than gopass and I can switch to it. I just want a great CLI password manager. It doesn't have to be maintained by myself. But please don't underestimate the maintenance effort.

Hello :)
Hope you are doing good !
About our usecases:

Gopass is used either by SRE and DEV teams
password stores are stored on gitlab
Each team member has its own GPG pubkey register in the gopass as recipients

Adding/Removing users is easy
We accept that removed users will still have access to previous entries

We store secrets such as (db passwords, Domain service account passwords, Apikeys, Tokens, ...)
We strongly use scripting in order to automatically set secrets as env vars

One nice concrete usecase:

We are using ansible, and we are using ansible-vault in order to encrypt secrets vars
ansible-vault use a password to encrypt/decrypt files
the password is stored in gopass
When using ansible, a script is automatically launch that will gopass show the secret and automaticaly encrypt/decrypt files

Hope this help !

My, this is a long thread I had missed before!
I haven't read every comment, but I'd like to add my two cents, as the maintainer of several tools based on Gopass, namely:

https://github.com/camptocamp/terraform-provider-pass
https://forge.puppet.com/camptocamp/hiera_pass

I actually found this by browsing issues today as I was working on a new integration: https://github.com/camptocamp/secrets-store-csi-driver-provider-gopass
At Camptocamp, we've been using pass and then gopass for years, and for lots of things:

sharing passwords between users
injecting secrets in Terraform (using our Terraform provider, as well as Summon)
injecting secrets in CI/CD & Kubernetes (using Summon mainly)
injecting secrets in Puppet in some cases

As painful as it is to work with GnuPG, it is a standard (which we use in other tools), and it allows users to have each their own key. Together with the mounts system in gopass, this gives us a great granularity in managing who gets access to which secrets.
Same goes for Git, which is extremly standard in our stack, and is of great value in Gopass.
We also use the OTP feature quite a bit.
Switching to Vault often comes back on the table of negotiations in our team. If Git and/or GnuPG support are dropped from Gopass, I don't think we'll have any good reason to keep using it.

@insoIite Thank you, that sounds almost exactly like the environment gopass was started in. I'd love to support this use case as good as possible. If anything is not working as expected let us know.
@raphink Sorry for the long thread. Luckily a lot of people care about this project and have expressed their concerns. I have just updated my initial post to better reflect current plans and softened the wording a bit.

I love gopass and the integration it has with git and gnupg. I missed this RFC, sorry.
I think an overlooked part is usability. If git is removed, people would have to do extra steps to achieve the same. It would be cumbersome to onboard teammates. I think there's where gopass shines :star2:
In the current version, for example the gopass -c operator was removed, which makes it longer to copy a secret, and makes lazy devs like me get sad haha.
OTOH I'd really like to see age as a backend as part of the core features, but I understand maintaining new features adds more time on devs.
I'm in for removing stuff which is not used. In the cheatsheet I made are my most used commands, it would be nice to know what people is and is not using.
I think this discussion was great, because it shows the functionality users really value about gopass.

Don't worry, @Woile  the -c, -u and --yes global flags are coming back in the next release ;)
Thank you for your cheatsheet, that's great to see what commands people are using 👍
BTW, if you are on Linux I recommend trying out the dmenu / rofi popup tip with xdotools, it's awesome: https://github.com/gopasspw/gopass/blob/master/docs/setup.md#dmenu--rofi-support

What about sigtool? Looks pretty similar to age at first sight, but does signatures as well.

Hi,
today I experienced how new 1.10 secrets break compatbility with other tools (e.g. PassIOS). First thanks for the big contribution over the past the steady flow of new features, awesome project. I've been using goPass since it's very first version.
I fully understand why you want to drop the compatibility with the original pass schema: it's very static, hard to maintain and especially to extend. It's logical, that for better and easier support, some external factors like GPG and GIT need to be dropped.
For me, the compatibility to pass (GPG+GIT), and therefore the possibility to human-readable decode every secret with normal upstream tools entirely based on internet standards is essential.
If humanity survives (or aliens will excavate us), it is much more likely that standartizied tools similar/compatible to PGP will be available than special decoding tools for other proprietary password chains.
So if you're asking me, I would prefer to see it hard-forked instead of loosing compatibility with every release.
I'll downgrade for now to 1.09, thanks for the fish!

Guess I'm going back to vanilla pass. Thank you for all your hard work, gentlemen, but I won't be following you down the path of audacious innovation.

Guess I'm going back to vanilla pass. Thank you for all your hard work, gentlemen, but I won't be following you down the path of audacious innovation. I don't agree with the ideology expressed in this thread, and would rather write my own tool than contribute here in the future. I care far more about familiarity, stability, and compatibility than ivy tower innovation; collaboration is impossible.
I wish you the best of luck.

Read https://github.com/gopasspw/gopass/issues/1365#issuecomment-632905976 .

Guess I'm going back to vanilla pass. Thank you for all your hard work, gentlemen, but I won't be following you down the path of audacious innovation. I don't agree with the ideology expressed in this thread, and would rather write my own tool than contribute here in the future. I care far more about familiarity, stability, and compatibility than ivy tower innovation; collaboration is impossible.
I wish you the best of luck.

Read #1365 (comment) .

I did read it. What's your point?

I've also noticed that the (deprecated) structured secrets feature which I've made frequent use of on my team has completely stopped functioning. This is with gopass config mime false. I really liked this feature and hope it will make a comeback.

@worldofgeese What do you mean by "structured secrets"?
The key-value secrets and the YAML secrets should still work as they used to before we introduced the MIME format.
If they don't work with mime false, then it's probably a bug and please open an issue :sweat_smile:

So, we have decided to keep GPG and Git, and are working on fixing the many issues introduced with 1.10.1.
I'm closing this for now, since it's lengthy and people might get the wrong idea that we are going to deprecate GPG and Git if they just read the first post.
Don't forget that it's very difficult for us to get feedback from our users (we don't even know how many users we have), so please feel free to open an issue as soon as something's off, if you have a question, or if we can improve something.
Notice that we might not necessarily add new features and might be trying to do a refactoring that would simplify the current codebase, but we will keep pass retro-compatibility (at least when the mime config option is set to false, and it should default to false with 1.10.2 to avoid all the hassles 1.10.1 caused.)

From the bottom of my heart, thank you devs for listening! 🥰

Thanks for this. Would you consider following semantic versioning for future versions? It's very surprising for users when major breaking changes are introduced between minor versions.

Just putting my 2cents.
After taking a look at different alternatives, I would love to see and use a gopass using age exclusively. I really appreciate simplicity in all aspects and GPG is something that is far from being simple. I'm also a use of Yubikey and after reading a lot of issues it seems like having hardware tokens support by using their plugin system + go-piv & PKCS#11 is not far away.
So just raising my hand telling you that I'm one of those unhappy GPG users since early-2000 waiting to have a better alternative. And age seems to be very promising IMHO.

@glerchundi We actually already have age somewhat supported with the age experimental backend: https://github.com/gopasspw/gopass/blob/master/docs/backends/age.md
We will happily have hardware token support as soon as it's ready on age's side :)

The latest release should make many of you happy. ;)
https://github.com/gopasspw/gopass/releases/tag/v1.11.0

The latest release should make many of you happy. ;)
https://github.com/gopasspw/gopass/releases/tag/v1.11.0

Thank you very much for your support @AnomalRoil ! It was crucial to getting this release done.
Everyone concerned about this issue please also read the short release notes in the Changelog:

This is an important bugfix release that should resolve several outstanding
issues and concerns. Since 1.10.0 was released was engaged in a lot of
dicussions and realized that compatability is more important than we first
thought. So we're rolling back some breaking changes and revise some parts of
our roadmap. We will strive to remain compatible with other password store
implementations - but remember this is a goal, not a promise. This means we'll
continue using compatible secrets formats as well as GPG and Git.

Thank you for your support and your constructive feedback.

Thank you very much for your support @AnomalRoil ! It was crucial to getting this release done.
Everyone concerned about this issue please also read the short release notes in the Changelog:

This is an important bugfix release that should resolve several outstanding
issues and concerns. Since 1.10.0 was released was engaged in a lot of
dicussions and realized that compatability is more important than we first
thought. So we're rolling back some breaking changes and revise some parts of
our roadmap. We will strive to remain compatible with other password store
implementations - but remember this is a goal, not a promise. This means we'll
continue using compatible secrets formats as well as GPG and Git.

Thank you for your support and your constructive feedback.

Thanks for that. Again, I do feel like following semantic versioning would help (0.10 would have been 2.0 and 0.11 would have been 3.0) to know what to expect from upgrades.

Thanks for that. Again, I do feel like following semantic versioning would help (0.10 would have been 2.0 and 0.11 would have been 3.0) to know what to expect from upgrades.

Technically, in semantic versioning 0.10 doesn't have to be backwards compatible with 0.9, since it hasn't reached 1.0 yet. See https://semver.org/#spec-item-4

Technically, in semantic versioning 0.10 doesn't have to be backwards compatible with 0.9, since it hasn't reached 1.0 yet. See https://semver.org/#spec-item-4

Yeah but we were at 1.10.1 and just released 1.11, but 1.11 should be
perfectly backward compatible. The odd one was 1.10 that had some breaking
changes, sorry for that one.
Note that Mime secrets were removed but we still have a legacy parser for
them in 1.11 parsing them, so no 1.X version should be broken by 1.11.

Yeah but we were at 1.10.1 and just released 1.11, but 1.11 should be
perfectly backward compatible. The odd one was 1.10 that had some breaking
changes, sorry for that one.
Note that Mime secrets were removed but we still have a legacy parser for
them in 1.11 parsing them, so no 1.X version should be broken by 1.11.

Well, public APIs are broken between 1.10 and 1.11 (e.g. GetBody() renamed to Body()).

Well, public APIs are broken between 1.10 and 1.11 (e.g. GetBody() renamed to Body()).

@raphink The semantic versions are supposed to have a meaning for the tool, not the API (yes, we've been bad at that as well, but we're trying to improve).
But adhering to semantic versioning and being compliant with go modules expecations around that for a binary and an API / Go Module in the same repository just doesn't work. So as long as gopass lives in one repo for both the tool as well the API you'll have to live with these kinds of changes. Sorry.

@raphink The semantic versions are supposed to have a meaning for the tool, not the API (yes, we've been bad at that as well, but we're trying to improve).
But adhering to semantic versioning and being compliant with go modules expecations around that for a binary and an API / Go Module in the same repository just doesn't work. So as long as gopass lives in one repo for both the tool as well the API you'll have to live with these kinds of changes. Sorry.


add screencasting option based on tmux

used by many software carpentry instructors.
Tested on macosx, iTerm2 v.3.3.6, tmux 2.9a

Nice find!  We should have known of this long ago.  I like how it automates so much.
For reference, this sets everything up including standardizing your shell, but uses history instead of a pre-exec function so doesn't log long-running commands until they are done.  And I like two separate windows, so that it the history window can have a smaller font.  Both are minor compared to the convenience of this!


add WorldDev Indicators ontology

I'm looking into it.  Just adding a file shouldn't cause any problems.

Unless maybe zheng_test2 wasn't passing in the first place.  it looks very old.  Can you make a new branch off master and add the file to that instead?

The file may need to change some, but it is used only when configured so I'll check it in if only as a placeholder for the good version.


Fleet Officer has wrong text

"at range 1-2" instead of "within range 1-2". The actual card differs from the preview card. ("at" and "within" have different definitions according to the faq).

The site has "within range 1-2", which agrees with the text on the card:

I'm not sure where you're getting "at range 1-2"?

From the real card...

Fleet Officer.jpg
https://docs.google.com/file/d/0B0dD5k8AOOx2cHpkVmpHb0FsLVE/edit?usp=docslist_api

Interesting. It seems most of the people online are using the version from fantasy flight's site (the post initially previewing the VT-49:
http://www.fantasyflightgames.com/ffg_content/x-wing/news/wave5/fleet-officer.png
There is also, near as I can tell, no errata about this card, and I am finding quite a mix of people quoting the text as both 'within' and 'at'. I think this is worth posting on the FF forums, and see if we can get some clarification.
I wil also check my cards when I get home tonight, and see which my physical copy says.

I'm not sure if i

I'm not sure if I can take credit/blame for this change a but I posted on this subject when it was previewed and :-)
http://community.fantasyflightgames.com/index.php?/topic/108818-fleet-officer-within-range-vs-at-range/

Sorry for that...  my phone bugged out

Confirmed that it's "at" on my physical card, and there is no errata for it, so I'll correct it.


Circular/Elliptical profile picture

Is there any way to change the shape of the profile picture displayed? I would like it to be a circle/ellipse.

#728 solved this.
Pull the latest commit. Update the image_circular variable in _pages/about.md to true.
https://github.com/alshedivat/al-folio/blob/bcd43a18fe67da84193fb6df21b0f27f993fe5f8/_pages/about.md?plain=1#L10

#728 solved this.
Pull the latest commit. Update the image_circular variable in _pages/about.md to true.
https://github.com/alshedivat/al-folio/blob/bcd43a18fe67da84193fb6df21b0f27f993fe5f8/_pages/about.md?plain=1#L10

Why did you used the word "cicular "in the code instead of "circular"? Is this a typo? @rohandebsarkar

@alpsencer It's a typo. Will fix it in a future PR.

@alpsencer It's a typo. Will fix it in a future PR.

I have already created a pull request.

@alpsencer, I did not notice your PR, if you can reopen it, I will merge.

@alpsencer, I did not notice your PR, if you can reopen it, I will merge.

Ok. I reopened. https://github.com/alshedivat/al-folio/pull/822

@alpsencer, I did not notice your PR, if you can reopen it, I will merge.

I put parenthesis on the previous PR's name, then I think it crashed the deployment. I fixed the name. I did not know that.


Auto-comment when a PR touches unowned code paths

I want to use Auto-comment Github action but I want to trigger it based on a unique use-case
Unique because it doesn't seem to be available off-the-shelf: https://github.com/marketplace/actions/auto-comment
I am using CODEOWNERS.md to define which code paths are owned by which teams within our org.
I now want to configure a GH action that would comment something like

Alert/Warning ⚠: You're touching 's codebase. Have you confirmed this change with them? Do they have knowledge of this?

Is it possible to tie in codeowners with auto-comment. If yes, can you recommend how? Thanks
Expected Behavior
Trigger auto-comment based on PR touching files in codeowners [created by author outside the owning team]
Possible Solution
Not sure

@bubkoo or @urish if you've some context


TSCBasic: remove uses of any from FileSystem.swift

In case any of our CI nodes still use older Swift with no support for any, it's better to remove this new keyword for now, especially as it has no impact on the behavior.

@swift-ci test

@swift-ci test linux

@swift-ci test linux

swiftpm/Tests/FunctionalTests/PluginTests.swift:1010: error: PluginTests.testPluginCanBeReferencedByProductName : XCTAssertTrue failed - stdout: seems unrelated but I'm not sure how to fix it


Sprint 4 Administration

Include meetings

Week 2 update meeting scheduled for April 18th @ 2:40pm. Still need to schedule the report meeting.


API Documentation Should Include Expected Exceptions

Which service(blob, file, queue) does this issue concern?
Blob
Which version of the SDK was used? Please provide the output of pip freeze.
azure-storage-blob v1.4.0
What problem was encountered?
The documentation for BaseBlobService does not include Exceptions that can be expected. For example, the get_blob_to_* methods simply state that they return a blob. But what happens if that Blob doesn't exist? This can theoretically happen even if you first verify that the blob in question exists.
Have you found a mitigation/solution?
Run functions locally to see what exceptions are produced. [This is not very comprehensive.] In a simple test that consisted of calling get_blob_to_text with a known non-existent file, I found that it raises the azure.common.AzureMissingResourceHttpError exception (which is also not documented...?).
This is important because Python tends to be EAFP rather than LBYL and having well-documented exceptions helps enable a EAFP development approach.

Any progress on this?

@zezha-msft any thought on this?

@xiafu-msft we should consider this item for track 2 instead.

Hi.
I'm working with this library and I detect that it is the same for cosmosdb.table.tableservice TableService (TableStorage)
Any update about this?


Error: afterSave for _User has already been registered

I'm getting this error when I try to deploy the cloud code:
Error: afterSave for _User has already been registered
    at Object.Parse.Cloud.afterSave (<anonymous>:440:5)
    at migrator.js:101:25
    at Function.T.each.T.forEach (underscore.js:17:779)
    at Migrator.exportTriggers (migrator.js:95:5)
    at main.js:140:10

The 140th line being:
 migrator.exportTriggers();
I have copied migrator.js, firebase-rest.js and consts.js and added this code to my main.js:
var migrator = require('cloud/migrator.js')(Parse);
var ref = require('cloud/firebase-rest.js')({
  url: '<url>',
  key: '<i_dont_know_where_to_find_this_key>',
  parse: Parse
});

 migrator.migrateObject(Parse.User, function(object) {
  // Testing
   return ref.child("/users/").child(object.id).put(object);
 });

migrator.exportTriggers();

What can be done here? Is this an issue or I have not followed the steps properly?
This project is great but the readme can be improved. As a former parse user, and I must admit I am a bit rusty, I'm finding it really hard to follow as the steps aren't mentioned clearly.

Ok, as the error message said afterSave for _User was already registered. My bad! I temporarily removed the afterSave on _User. Where should the afterSave code be written in case of handing migration as well?

Migrator has its own beforeSave and afterSave functions that can be used. The library needs do some weird tricks so I had to separate a "logical" before/afterSave from a real one.
With respect to keys, they've been deprecated in favor of Google's stronger crypto. The param is needed for admin-level access. If you need that, email me at my GitHub handle @ google.com and I'll get you sorted out. Also, check out the latest Firebase CLI release--it now supports importing user auth data!

Thanks a lot, that solved it! :) I will email you about bypassing the rules.json. I checked the CLI, it's really helpful, gives us and option to bulk import the data but migration using cloud code seems like the best option for us at will run for 2 more months and keep firebase data updated.


Jumpstart deploy vFXT cluster example not working - Last step

Hi, I'm trying to configure an Avere vFXT cluster to mount it into an Azure Batch pool, and I'm following this quickstart tutorial:
https://github.com/Azure/Avere/blob/master/docs/jumpstart_deploy.md
But when I SSH to the controller node ,modify the deployment template and try to run the template in the controller node (the last step of the page) I get this error:
Traceback (most recent call last):
File "/usr/local/bin/vfxt.py", line 4, in
import('pkg_resources').run_script('vFXT==<IP_ADDRESS>', 'vfxt.py')
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 3088, in
@_call_aside
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 3072, in _call_aside
f(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 3101, in _initialize_master_working_set
working_set = WorkingSet._build_master()
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 576, in _build_master
return cls._build_from_requirements(requires)
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 589, in _build_from_requirements
dists = ws.resolve(reqs, Environment())
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 778, in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'secretstorage<3; (sys_platform == "linux2" or sys_platform == "linux") and python_version < "3.5"' distribution was not found and is required by keyring
It seems that there's something that's not installed in the controller node (I also had to install enum34 package via pip because on a previous step I got this error:
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 174, in _run_module_as_main
"main", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/usr/local/lib/python2.7/dist-packages/azure/cli/main.py", line 9, in
from knack.completion import ARGCOMPLETE_ENV_NAME
File "/usr/local/lib/python2.7/dist-packages/knack/init.py", line 6, in
from .cli import CLI
File "/usr/local/lib/python2.7/dist-packages/knack/cli.py", line 10, in
from .invocation import CommandInvoker
File "/usr/local/lib/python2.7/dist-packages/knack/invocation.py", line 10, in
from .util import CLIError, CtxTypeError, CommandResultItem, todict
File "/usr/local/lib/python2.7/dist-packages/knack/util.py", line 9, in
from enum import Enum
ImportError: No module named enum
tying to execute command "az login" inside the controller node.
I'm using Azure Cloud Shell.
I googled the error but I didn't find anything useful
Can you check it please?
Thanks!!

Ok, I figured out, I had to install this package on the controller node:
https://pypi.org/project/SecretStorage/
Regards!


Inconsistent population of docnumbner

The record retrieved for ISO/IEC 646 includes a <docnumber> value.
The record retrieved for ISO 8601-2:2019 includes a <docnumber> value.
The record retrieved for ISO 80000-1 does not include a <docnumber> value.

Sorting bibliographies in ISO depends on an accurate docnumber value being present, since docnumber is a sort key.

@opoudjis I unable to reproduce the issue:
[1] pry(main)> require 'relaton_iso'
=> true
[2] pry(main)> item = RelatonIso::IsoBibliography.get 'ISO 80000-1'
[relaton-iso] ("ISO 80000-1") fetching...
[relaton-iso] ("ISO 80000-1") found ISO 80000-1:2009
=> #<RelatonIsoBib::IsoBibliographicItem:0x007fc21d4ac608
...
[3] pry(main)> item.docnumber
=> "80000"
[5] pry(main)> item.to_xml
"<bibitem id=\"ISO80000-1\" type=\"standard\">
...
  <docnumber>80000</docnumber
...

relaton-iso v 1.0.1

Just confirmed. The issue must be my side somehow.


sequence_bucketized_column is missing

System information

Have I written custom code (as opposed to using a stock example script provided in TensorFlow): No
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): N/A
TensorFlow installed from (source or binary): binary
TensorFlow version (use command below): v1.8.0-0-g93bc2e2072 1.8.0
Python version: 3.6
Bazel version (if compiling from source): N/A
GCC/Compiler version (if compiling from source): N/A
CUDA/cuDNN version: N/A
GPU model and memory: N/A
Exact command to reproduce: N/A

Describe the problem
TensorFlow 1.8 introduced a new API for sequence feature columns. The API covers categorical, numeric columns, but lacks sequence_bucketized_column. It should not be hard to implement, so if that's OK with you, I can do it myself and submit a PR.
Source code / logs
N/A.

@ispirmustafa please review for API addition. We're ok with it if you are.

it should work this way: bucketized_column(sequence_numeric_column(...), ...)
To do that, you need to update _BucketizedColumn. You can check the implementation in _EmbeddingColumn.
I'm okay with adding sequence support to bucketized column.

Thanks for the pointers @ispirmustafa. Should I make _BucketizedColumn dense or categorical, or both? The latter will require removing _CategoricalColumn from the base classes of _SequenceCategoricalColumn because otherwise the MRO for _BucketizedColumn will be ambiguous:
                 _____________________  _FeatureColumn -----------
                /           /                |                     \
               /           |         _CategoricalColumn             |
               |           |                 |                      |
_CategoricalColumn  _DenseColumn  _SequenceCategoricalColumn _SequenceDenseColumn
                \          |       |                         /
                 -- _BucketizedColumn -----------------------

Hi @superbobry
good point. let's remove _CategoricalColumn inheritance from _SequenceCategoricalColumn. that will be better.

Nagging Assignee @ispirmustafa: It has been 14 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @ispirmustafa: It has been 29 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @ispirmustafa: It has been 25 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Nagging Assignee @ispirmustafa: It has been 39 days with no activity and this issue has an assignee. Please update the label and/or status accordingly.

Hi @superbobry
Could you please update this thread? thanks

It has been 14 days with no activity and the awaiting response label was assigned. Is this still an issue?

It has been 29 days with no activity and the awaiting response label was assigned. Is this still an issue?

It has been 44 days with no activity and the awaiting response label was assigned. Is this still an issue?

Closing the issue due to inactivity.

What's missing on your WIP implementation @superbobry?

Any progress for this feature?


Simplified driver interface

BREAKING CHANGE: refactored driver interface

Codecov Report

Merging #64 (0066d44) into main (09a224c) will decrease coverage by 1.31%.
The diff coverage is 90.90%.

@@            Coverage Diff             @@
##             main      #64      +/-   ##
==========================================
- Coverage   85.32%   84.01%   -1.32%
==========================================
  Files          12       12
  Lines        1131     1057      -74
==========================================
- Hits          965      888      -77
- Misses        125      127       +2
- Partials       41       42       +1

Impacted Files
Coverage Δ

client/database.go
27.08% <ø> (ø)

driver/internal.go
100.00% <ø> (ø)

driver/driver.go
96.87% <80.00%> (-1.05%)
:arrow_down:

driver/http.go
75.42% <88.88%> (-1.96%)
:arrow_down:

driver/grpc.go
87.66% <100.00%> (-0.72%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 09a224c...0066d44. Read the comment docs.


bash: npm: command not found

I've installed node.js and all other steps seemed to work but wen I get to the end and type "npm install m2x, I get bash:  npm: command not found.  Thoughts?
Command Line on a Raspberry Pi

Sounds like the path may not be complete and it can't find your npm install?   http://oskarhane.com/raspberry-pi-install-node-js-and-npm/
Can you try: npm -v

Closing this one as a stale ticker, @lifeonmobile feel free to reopen or open a new ticket if you have further questions!


Allow for custom URLs to pass to the SDK in tjbot library

The TJ bot library hard-codes the URL to https://stream.watsonplatform.net/speech-to-text/api/ . And in cases where clients are operating services outside of the US-region, it will be necessary to change the URL to gain access to the service. For example, Speech to text services created in this Sydney region will need to use the endpoint https://gateway-syd.watsonplatform.net/speech-to-text/api . Please enable custom URLs to pass to the SDK in this library.

Great suggestion! Please check out this branch and let me know if it works for you (I haven't tested this at all so hopefully I didn't make any typos…)
https://github.com/ibmtjbot/tjbotlib/tree/feature/jw-customurl
If this is good, I'll merge it in to master and bump the lib to v1.5.

This has been added in tjbotlib 1.5. Thanks.


cli-wallet distinguishes between True and true

works: transfer nathan client1 999 CORE "" true
does not work: transfer nathan client1 999 CORE "" True (in the sense that the wallet broadcasts the tx)

OK, a while ago I re-wrote FC's JSON parser.  The new relaxed parser interprets unquoted non-keyword values as strings, so at the JSON level true gets converted to boolean true, but True gets converted to the string "True"; you can see that logic implemented here.
Then when JSON is converted to bool, it converts the string "true" to the bool true and all other strings to the bool false; that's part of fc::variant implemented here.
I think in the second place, the string_type case of the switch statement needs to reject any value other than "true" or "false".

Recompile with the above commit, True -- or any value other than true or false -- should now throw an exception.


Chaning the color of Core-toolbar

Using core-scaffold and core-toolbar to create a navigation menu. Codepen (example): http://codepen.io/anon/pen/MYbrmO
But  I can't menage to edit the background-color of the toolbar next to the navigation, it stays blue.
With CSS to style it by giving it a class and even in the element itself doesn't change anything.
Am I doing something wrong?

The core-toolbar in the scaffold is part of the element's shadow dom. You can use ::shadow to select and style it:
core-scaffold::shadow core-toolbar {
  background-color:grey;

}
Alternatively, you can style all toolbars anywhere in shadow dom using:
html /deep/ core-toolbar {...}

Wow, thanks alot for the fast response!
Fixed.

That doesn't work on firefox :-1:

@NitroBAY if you're using the shadow DOM selectors (/deep/, ::shadow, ::content) in a document-level stylesheet, you need to add shim-shadowdom to the <style> tag:
<style shim-shadowdom>

See:
https://www.polymer-project.org/0.5/docs/polymer/styling.html#sdcss

Thanks


 Rubocop will at least make it  consistent.

Do you think we should just configure it according to the defaults on the Ruby style guide?

Implemented #47


Bump version of druid-basic-security

Looks like #5138 missed out bumping the version of extension: druid-basic-security

@a2l007 could you keep the file to have \n in the end?

@a2l007 :+1:, thanks!


Onboard Localization pipeline

Sample run https://github.com/dotnet/vscode-csharp/pull/5987
https://dev.azure.com/dnceng/internal/_build/results?buildId=2234885&view=results
This PR contains two localization file changes. One in code and one in package.json as the test sample.
In code, it uses vs-l10n to do localization.
The pipeline works like this:

Extract localization strings to bundle.l10n.json. (l10n-dev)
Convert them into .xlf file. (l10-dev)
Use OneLocBulid task to generate translated .xlf file (OneLocBuild)
Import all the translated file back to json under l10n folder. (l10n-dev)
Use dotnet-bot to submit a PR back to main on GitHub.

I feel it is enough to always translate our main branch here. If there is any problem we can address it in the future.
After this, two more things are needed.

Ask the LOC team to onboard our repo to their list, so that all things are get translated.
Extract all the strings, and package.json to use l10n, this might be in another PR.

Because Phil merged this https://github.com/dotnet/vscode-csharp/pull/5962 so there are more strings need localization : )


QuerySnapshot.docChanges has been changed from a property into a method

This means that the FriendlyEats.prototype.getDocumentsInQuery() function is wrong.
The function should be updated to reflect the change from a property to a method, like so:
FriendlyEats.prototype.getDocumentsInQuery = function(query, render) {
  query.onSnapshot(function(snapshot) {
    if (!snapshot.size){
      return render();
    }
    var changedDocs = snapshot.docChanges();
    changedDocs.forEach(function(change) {
      if (change.type === "added"){
        render(change.doc);
      }
    });
  });
};

I would love to take on a pull request, if that is okay?

@Vanluren a pull request would be great!

Great, I'll take a look at it right away!

Closed:
https://codelabs.developers.google.com/codelabs/firestore-web/#5


Resolution issues in SDL_WINDOW_FULLSCREEN with HIDPI and touch handling

Hi, I'm trying to get some code working with SDL_gpu and SDL2 on both Retina Macs and high DPI Android devices (e.g. Galaxy S7) in SDL_WINDOW_FULLSCREEN.
The Android device seems to report its screen dimensions from SDL_GetDisplayMode (but also the GPU_Target returned by GPU_Init's .base_w / .base_h) in actual pixels, whereas the Mac reports it in (retina-scaled) points. This means dimensions I provide to GPU_Init end up being wrong on one device or the other. I've been going around in circles for days: either my touch handling is wrong (all hits are boxed into one corner) or the display scale is wrong (display boxed into the corner but touch handling correct etc.) on one of the platforms.
I've all sorts of things to get around this, like manually changing .w and .h of the GPU_Target provided by GPU_Init, getting the SDL_DisplayMode dimensions after init and calling GPU_SetVirtualResolution to them, trying various manual mathematical acrobatics. GPU_GetVirtualCoords doesn't seem to do anything on the Android device and seems to give me the wrong coordinates on the Mac (which doesn't seem to need any adjustments to pixel coordinates in HIDPI by default). In any case, if I fix it on one, it's broken again on the other.
It seems like SDL_GL_GetDrawableSize and comparing it to the SDL_DisplayMode dimensions would be the way of finding out the real scale factor of the pixels, at which point I could adjust the scale of things manually. That function only seems to work with an SDL_Window though, which isn't available after starting SDL with GPU_Init (or is it?).
I couldn't see any clear way of doing this in the docs, can you recommend a way forward? I was considering doing an OS check for Android and implementing different logic there, but it seems risky, because I couldn't be sure that all devices behave in the same way. I'd much rather get a real content scale factor if it's possible!

SDL_gpu does use SDL_GL_GetDrawableSize to try to avoid the HIDPI issue, so it sounds like it's just not doing it right.  If I get some time, I'll try to look into it on a retina device.
You can get the windowID from the screen target: screen->context->windowID and use SDL_GetWindowFromID() to get the SDL_Window.  Maybe you can get further with that for now?

@grimfang4 thanks for the tip about context->windowID, I have just hacked this for now with OS-dependent conditions but will probably have another look at it soon


[polymetis] Fix orientation planner

Description
Fixes the way rotational velocities are being computed during min-jerk trajectory generation by using the left-hand notation for rotations (see this article for more technical details).
Since only the velocities are erroneous, current EE move to experiments only experience visible inaccuracies when the positional gains aren't able to complement the wrong damping forces. We were able to notice the issue because the wrist joint (which has a low Kp/Kd ratio) was going off in the wrong direction in some experiments.
Type of change
Please check the options that are relevant.

[x] Bug fix (non-breaking change that fixes an issue)
[ ] Proposes a change (non-breaking change that isn't necessarily a bug)
[ ] Refactor
[ ] New feature (non-breaking change that adds a new functionality)
[ ] Breaking change (fix or feature that would break some existing functionality downstream)
[ ] This is a unit test
[ ] Documentation only change
[ ] Datasets Release
[ ] Models Release

Type of requested review

[x] I want a thorough review of the implementation.
[ ] I want a high level review.
[ ] I want a deep design review.

Before and After
If this PR introduces a change or fixes a bug, please add before and after screenshots (if this is causes a UX change) or before and after examples(this could be plain text, videos etc ) to demonstrate the change.
If this PR introduces a new feature, please also add examples or screenshots demonstrating the feature.
Testing
Tested on hardware.
Checklist:

[x] I have performed manual end-to-end testing of the feature in my environment.
[ ] I have added Docstrings and comments to the code.
[ ] I have made changes to existing documentation where needed.
[ ] I have added tests that show that the PR is functional.
[x] New and existing unit tests pass locally with my changes.
[x] I have added relevant collaborators to review the PR before merge.

Let's add a unit test for orientation planning?


bad email<EMAIL_ADDRESS>

The email address is not found:
The response from the remote server was:
550 5.1.1<EMAIL_ADDRESS>Recipient address rejected: User unknown in local recipient table
I'm a new contributor and am trying to email the required contributor's license.

You sent to     , but need to send to

Actually, please clarify: did you copy/paste from somewhere or type in manually?

I used OCR to read the italicized email address from the agreement.    Thanks.

You sent to [ell] [ee] [gee] [a] [capital i], but need to send to [ell] [ee] [gee] [a] [ell]

Good catch, I'm amazed you figured this out so quickly @kaduk. In a fixed size font, the error would have been obvious:
550 5.1.1<EMAIL_ADDRESS>Recipient address rejected: User unknown in local recipient table

I mean, I read email in mutt in a terminal with a fixed-width font specifically chosen to disambiguate such "confusables".  Given those preconditions, it was pretty easy to see :)

Can someone help me find my glasses? ...

Can someone help me find my glasses? ...

You can find them right there in your avatar.


feat: attest integration

Description

closes https://github.com/vitest-dev/vitest/issues/5857

Based on https://github.com/vitest-dev/vitest/pull/6852, now I moved all code to core.
summary
Add new assertions:

toMatchTypeSnapshot/toMatchTypeInlineSnapshot
toMatchTypeErrorSnapshot/toMatchTypeErrorInlineSnapshot
toMatchTypeCompletionSnapshot/toMatchTypeCompletionInlineSnapshot

and a new option to "enable" them (without the option, assertions become no-op and no-error):

vitest --attest
or defineConfig({ test: { attest: true } })

Example on stackblitz https://stackblitz.com/edit/vitest-dev-vitest-ywts26?file=test%2Fbasic.test.ts
example code
test('inline', () => {
  expect(squared).toMatchTypeInlineSnapshot(`(n: number) => number`);

  expect(() =>
    // @ts-expect-error
    squared('foo')
  ).toMatchTypeErrorInlineSnapshot(
    `Argument of type 'string' is not assignable to parameter of type 'number'.`
  );

  expect(
    () =>
      // @ts-expect-error
      squared['a']
  ).toMatchTypeCompletionInlineSnapshot(`
    {
      "a": [
        "apply",
        "arguments",
      ],
    }
  `);
});

todo

[x] implement assertions

[x] type
[x] errors
[x] completions

[x] config to enable attest

[ ] support custom ATTEST_tsconfig

[ ] doc
[ ] polish

vitest

[ ] avoid new Error().stack for for non type assertion expect(xxx) (how?)
[ ] error handling for mis-usage, default behavior on CI etc...
[x] prompt install
[x] remove PrettyFormatSkipSnapshotError hack

attest

[x] programmatic API for precache
[ ] avoid cwd reliance on runtime

allow ATTEST_assertionCacheDir option https://github.com/arktypeio/arktype/blob/a5f7e4b2b857f2275e8ea03d9895d12db3076b42/ark/attest/config.ts#L149-L151
what to do with getFileKey? https://github.com/arktypeio/arktype/blob/776ce7e85becf7614b4ad4def65d0d90df9c908a/ark/attest/utils.ts#L5

[ ] avoid analyzing non type assertion expect(xxx) (can be later)
[ ] avoid fs and process on runtime (later for browser mode)

https://github.com/arktypeio/arktype/blob/a5f7e4b2b857f2275e8ea03d9895d12db3076b42/ark/attest/cache/getCachedAssertions.ts#L26

[ ] make it work on stackblitz https://stackblitz.com/edit/vitest-dev-vitest-ywts26?file=test%2Fbasic.test.ts

rerun broken? (their file system issue?)

tbd

[ ] config , default behavior, etc...
[ ] workspace support? (currently attest runs independently for each project with { attest: true })

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[x] Ideally, include a test that fails without this PR but passes with it.
[ ] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[ ] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

@mrazauskas Hi, first of all, thanks for testing out!
About what's printed in the snapshot, we've talked with arktype/attest author @ssalbdivad. If I remember correctly, that's what we can get from ts server api. Normally it should match with what you see when hovering on IDE, but vscode can somehow show namespace without getting stripped.
We're not familiar with this area, so mostly we'll need to delegate to what attest supports for now even if we integrate some features as Vitest builtin. I guess this feature will start as experimental and see if the representation makes sense to users in general.

We're not familiar with this area

Fair enough. I mean.. Are you about to ship this feature knowing that you are not familiar with it?

In terms of API, I'm mostly only using writeAssertionData from @ark/attest, which analyzes xxx inside expect(xxx) and then output .attest/assertions/typescript.json file.
This in turn uses ts.typeChecker.typeToString API from typescript. https://github.com/arktypeio/arktype/blob/649f70eb2ec48b5203099469c6b59d0b5fe29260/ark/attest/cache/ts.ts#L208-L230 If the limitation is typescript API level, then Vitest cannot change anything for the snapshot though :thinking:


fix_format_in_api_spec

What type of PR is this?
Add one of the following kinds:

correction

What this PR does / why we need it:
Fix API spec format
Which issue(s) this PR fixes:
Fixes #38
Special notes for reviewers:
Cover this
code/API_definitions/blockchain_public_address.yaml
Error: 10:1 [trailing-spaces] trailing spaces
Error: 58:11 [indentation] wrong indentation: expected 12 but found 10
Error: 114:11 [indentation] wrong indentation: expected 12 but found 10
Error: 163:11 [indentation] wrong indentation: expected 12 but found 10
Error: 241:1 [trailing-spaces] trailing spaces
Error: 257:17 [trailing-spaces] trailing spaces
Error: 293:1 [trailing-spaces] trailing spaces
Error: 309:17 [trailing-spaces] trailing spaces
@rartych

regarding indentation errors do not sure needed more indentation but doing as linter indicates (is it ok in this way?)
do not identify any point missed regarding Error: 293:1 [trailing-spaces] trailing spaces

@grgpapadopoulos

please approve it so i can check again linter

Thanks Rafal, Georgios!! Going to merge and test with the new commonalities configuration


python3Packages.tifffile build failure on x86_64-linux as of dc9bf840

Issue description
Build of python3Packages.tensorflow-datasets failed on x86_64-linux as of dc9bf840d3b1b35bf88b7de5caa2360f537cbe1a.
build log
Maintainer cc: @ndl
Other cc: n/a
Steps to reproduce

Checkout nixpkgs at commit dc9bf840d3b1b35bf88b7de5caa2360f537cbe1a
Run nix-build -A python3Packages.tensorflow-datasets

Technical details
- system: `"x86_64-linux"`
 - host os: `Linux 5.11.0-1028-azure, Ubuntu, 20.04.3 LTS (Focal Fossa)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.6.1`
 - nixpkgs: `/nix/store/6v2wg6ycxzrqwn5g2pxfvx5700vddq9a-source`

Misc.
This issue was automatically generated by nixpkgs-upkeep.

CI workflow that created this issue.
Internal tag:<PHONE_NUMBER>406861983

Root cause seems to be that the python3Packages.tifffile package is broken:
error: builder for '/nix/store/n42xlrk0rlkv3ksczg6x2sdbha0c2agx-python3.9-tifffile-2022.2.9.drv' failed with exit code 137;
[30805](https://github.com/samuela/nixpkgs-upkeep/runs/5312025910?check_suite_focus=true#step:9:30805)

cc @lebastr

Why does python3Packages.tensorflow-datasets use a tifffile different from python3Packages.tifffile?

Never mind, it doesn't and python3Packages.tifffile actually builds just fine.

Yes, looks like it was fixed somewhere between https://github.com/NixOS/nixpkgs/commit/dc9bf840d3b1b35bf88b7de5caa2360f537cbe1a and 9c70e731165e0f99c43406855311002b5ad4918f.