(1password) proposed package revisions

[virtualex-itv]

I've been taking a look at this package and recently had a quick chat about it with @mkevenaar. Collectively, we thought it'd be best to bring the discussion here to see how we'd like to move forward with this package as it's currently out of date. We have (2) ideas for this package:

1. keep the package "as is" and update it to support 1password 8.x
2. Modify the package to also support (1password 8.x) but then create (3) new packages for 1password 4.x, 7.x, & 8.x and use the original package as a version dependency in each of the new packages. This would allow for the installation of the desired version by the end user and in my opinion, the preferred route.

What does the community think?

Reference: Issue #1773

Upgrade to 1Password 8 for Windows

[pauby]

Is there much to be gained by creating a 4.x and 7.x package? Will / are they still used?

[AdmiringWorm]

Since we already support the package 1password4 it is best to keep it around, might be an idea to split that portion out to a manual package instead of being an automatic anymore.

For the 7.x, new releases are still being released it seems (latest release 2022-07-13).
So either having a new stream for it, or split it out to a new package should probably be done.

Could split out the 8.x to its own package as well and convert the normal 1password package to a meta package depending on the exact version.

I vote for splitting up the package, instead of using streams

[egerlach]

I just started a similar conversation on Discord, and I was redirected here, where I found this, so I'm adding to it instead of making a new discussion. I'm going to copy-paste some of what transpired there. I intend to start acting on things pretty quickly here, I already have a PoC for parsing the 1password 8.x release stream.

I wrote on Discord:

Hi #packaging , I have been sufficiently frustrated with 1password that I am working on fixing it. This is my first foray into chocolatey packaging, but I'm an experienced dev/sysadmin. I see a number of issues currently with the package:

1. Version 8 isn't packaged, latest version is 7.9.x
2. (1password) install appears to succeed, but program is not functional #1618 (install doesn't work) doesn't seem to be resolved >yet
3. 1password vs. 1password4: Should the logic be completely separate? as discussed in https://github.com/chocolatey-community/chocolatey-packages/pull/1733/files#r748143214
4. Finishing the refactoring started in (virtualbox) Add missing dependency for 7.0 stream #2041 (extracted helper functions)

After reading previous issues/PRs/Disqus comments, I've started to dig in. I have some questions and I'm hoping for some guidance.

1. As suggested by @jacktose, I'm parsing https://app-updates.agilebits.com/product_history/OPW8 to get the 8.x stream's versions. They have release, BETA, and NIGHTLY versions there.
   a. It seems like pushing 3 streams (OPW, OPW-BETA, and OPW-NIGHTLY) would make sense from the data available on the page. Any issues with that?
   b. I propose parsing https://app-updates.agilebits.com/product_history/OPW6 and https://app-updates.agilebits.com/product_history/OPW4 the same way to get the latest versions from those streams as well. That way, someone who doesn't want v8 can get the latest v7 (which is on the OPW6 page, confusingly)
2. Based on https://support.1password.com/deploy-1password/, it says that the .exe installer should be used for per-user installation, and .msi for machine-wide installation. Does chocolatey-community have a recommended practice when faced with a situation like this? I suspect moving to the MSI installer might resolve (1password) install appears to succeed, but program is not functional #1618. Is there a way to support both and is that worth doing?

[egerlach]

@TheCakeIsNaOH replied to me:

It seems like pushing 3 streams (OPW, OPW-BETA, and OPW-NIGHTLY) would make sense from the data available on the page. Any issues with that?

In general, that would be ok. If it was my package, I might split it up into two packages, one with OPW and the OPW-BETA streams, and another package for the OPW-NIGHTLY. That way, people can select between release and beta by using --prerelease, or select the nightly via installing the nightly package. But having all of those under one package ID would work as well.

I propose parsing https://app-updates.agilebits.com/product_history/OPW6 and https://app-updates.agilebits.com/product_history/OPW4 the same way to get the latest versions from those streams as well.

Sounds great to me.

Does chocolatey-community have a recommended practice when faced with a situation like this? I suspect moving to the MSI installer might resolve #1618 . Is there a way to support both and is that worth doing?

If it was a new package, I would 100% go with the .msi installer. Using a machine wide installer with Chocolatey is better, as it works with multi-user machines, or when Chocolatey is running as a separate admin account (or as SYSTEM).
I'm not sure what the best option is since this is a pre-existing package.

[egerlach]

I replied to that, just now:

Thank you for your thoughts, I'm going to migrate them to a GitHub discussion. RE: msi vs. exe., I wonder if it's worth ultimately moving to 3 packages: 1password, 1password.install, and 1password.msi, with the first as a virtual package that depends on the second (for now) and then someday we can transition if we want. I've seen other packages use similar patterns. Names aren't set in stone, would need to think about that a bit.

And you make a really good point with the --prerelease flag. That should have one and only one meaning. So now we have exe vs. msi and prod/beta vs. nightly. That's 12 packages! YAY! (I'm kidding, this will need some thought, over on GitHub, which I'm doing now)

Which brings us to the present. I'm going to be working on this on-and-off over the next week, and I hope to have something to show for it pretty soon.

[egerlach]

Reading more, I think the right way to differentiate the MSI package is like Microsoft Teams¹²: 1password does what it does today and installs the user desktop app, and 1password.install should do the machine-wide MSI install.

Footnotes

1. https://community.chocolatey.org/packages/microsoft-teams ↩

2. https://community.chocolatey.org/packages/microsoft-teams.install ↩

[egerlach]

I also see that #1821 discusses the MSI installer idea, and notes that it might not be reliable in the future and that we'd be guessing at the URL, which is a good point. I personally would still want an MSI version and I'll create one privately regardless of whether it ends up in the community repo.

[egerlach]

In terms of a plan, this is what I'm thinking right now:

• 🚧 Change the 1password package to parse the new releases page rather than depending on the redirect link (see (1password) Add support for 1password v8.x (fixes #1773) #2108)
  • The new package would have release and prerelease (beta only) versions
  • A 7.x stream would be maintained
• Move 1password4 package to be a manual package (@AdmiringWorm suggested it, and I independently was already thinking the same thing)
• Finish the refactoring started in (virtualbox) Add missing dependency for 7.0 stream #2041 by using the extracted helper functions
• Add 1password.install package which installs MSI version of 1password
• Convert the 7.x stream into its own package
• Consider adding -nightly versions, if anyone cares

[egerlach]

I have submitted #2108 to add v8 support.

[egerlach]

@egerlach I recommend holding off on making any changes to this pull request for now.

We have had some internal discussions about whether we should keep maintaining this package in this repository, create an RFM request to give it away to new maintainers or ask the developers of 1password if they are interested in taking over the maintenance.

I'll move this PR into a draft for now, but it may be closed once a decision and a result have been achieved.

Originally posted by @AdmiringWorm in #2108 (comment)

I'll add my personal thoughts here. I use this package personally, so I'll maintain my own version no matter what. I would prefer to be able to do that within the context of and with the support of chocolatey-community, as I'm new at this, but would understand if it doesn't fit. I would also be willing to see if I could assist with AgileBits, but that could prove more complicated (for employment/corporate reasons).

As for the future of the packages in general, first, I think that 1password4 should move to being a manual package and should be maintained by chocolatey-community. There are people who still use that package because it was the last version that supports offline vaults, IIRC.

In terms of the main 1password package, I think that:

1. It should be re-written from scratch using more modern patterns; and
2. It should use the MSI as its basis.

As I've been learning more about chocolatey packaging through this experience, I've found that interacting with the existing install/uninstall mechanisms for the .EXE-based installer, which is designed to install for a single user, are quite fragile. There also seems to be stuff in there that I'm afraid of touching because it seems to serve some purpose, but I don't know what.

There have been previous discussions about using the MSI installer in the past, specifically whether it meets chocolatey-community's standards to use. I argue that it does, though in a circuitous way. They do link to it on their website, but the version number isn't available in the url they provide. Once you've downloaded the file from that URL you can either:

1. Use the information on their app-updates site to "guess" another URL for the MSI that includes the version number and compare them; or
2. Use Windows Installer and PowerShell to extract the version number from the MSI.

Regardless of how one confirms the version number, one can parse the app-updates site (as in my PR) to determine if a new version is available in order to prevent unnecessary downloads.

For me personally the MSI version is more valuable and if I had my druthers I'd prefer to focus on that. I'm already building it for personal use and hosting it on my repo on my home network. With that said, it's more valuable to me to work in the context of chocolatey-community and have that support, and I would be content to assist in maintaining both EXE and MSI installers. I just don't know if I will have the time to do that if I'm out on my own as well, if that makes sense.

Take what you will of this into your internal conversation, looking forward to hearing how it goes, and I'll pause any work on the PR that doesn't support my personal needs. Thanks for being clear about where you're at with this. It's far better to know than to be left guessing.

[pauby]

I've not got anything to add to this beyond saying that this is what this repository is looking for - community members who are willing to pick up and maintain a package but use the setup already provided and working here for the automation.

For me, it would be ideal if the vendor can pick up and maintain a Chocolatey package for 1Password, as it is used by many people. If that is not feasible, I would like to see this repository keep it, but only if we had somebody who has experience with 1Password and a desire to maintain it with community help.