search

chocolatey-community / chocolatey-packages

Chocolatey Community Maintainers Team Packages - packages that are managed and maintained by core community team for community package repository (https://community.chocolatey.org/packages)
https://community.chocolatey.org/profiles/chocolatey-community
Apache License 2.0
446 stars 377 forks source link

(autohotkey) Create virtual, v1 and v2 packages #1710

Closed majkinetor closed 4 months ago

majkinetor commented 3 years ago

AHK v2 is dramatically different from AHK v1. Given the importance of this package for unattended installations, I propose the following:

  1. Current ID autohotkey should become virtual package
  2. Rename current autohotkey to autohotkey1
  3. Create new package, autohotkey2
  4. Via streams, make autohotkey to contain all releases from both versions.

Example for this methodology is done once by me in package PostgreSql and seems to work fine as one can choose major version but also choose not to care and entire thing is easily discoverable.

Alternatively, we could leave autohotkey as it is, and create set of new packages with different names: ahk, ahk1, ahk2 and deprecate autohotkey to target ahk1. Seems more clean and I like shorter name.

Also, this would have to handle portable variants. So its some work, but it could be done as single package with 5 streams.

If done, this would make #1663 and its PR obsolete.

Thoughts ?

github-actions[bot] commented 2 years ago

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue will be closed in 14 days if it continues to be inactive.

github-actions[bot] commented 2 years ago

Dear contributor,

As this issue seems to have been inactive for quite some time now, I've automatically closed it. If you feel this is a valid issue, please feel free to re-open the issue if/when a pull request has been added. Thank you for your contribution.

slycordinator commented 1 year ago

This issue is valid/relevant.

Currently: 1) many packages depend on autohotkey.install, which is currently is on version 1, and use version 1 syntax for their AHK scripts. 2) autohotkey.portable is currently at version 2 3) autohotkey.portable places the version 2 'AutoHotkey.exe' into $env:ChocolateyInstall\bin 4) And packages that use autohotkey.install and expect version 1 will call 'AutoHotkey', which then runs the version 2 executable from above because it's in chocolatey's PATH, and the user receives popups of syntax errors.

edit: Similarly, there are some packages that depend on autohotkey.portable that haven't been updated to use scripts compatible with it. Additionally, packages may have a difficult upgrade process if the installed package can only be uninstalled with an AHK script that uses v1 when the AHK packages already upgraded themselves to v2.

pauby commented 1 year ago

I've reopened this issue as I noticed 1.1 is deprecated, so we can't just leave everything at v1.

If a package has a dependency on autohotkey or autohotkey.install (latest is 1.1.36.02), and they install another package that requires autohotkey.portable (latest is 2.0.2) then the AuotHotkey software will be upgraded to 2.0.2 overwriting the 1.1.36.02 version. You can't have both versions of AutoHotkey installed.

We have:

This is a bit of a mess.

It appears that you can install both v1 and v2 of AutoHotkey and v2 will therefore be able to execute v1 scripts. I don't know how this works with portable versions, as I haven't looked at that yet. However, I have submitted #2246 for the autohotkey.install v2 version that includes backwards compatibility with v1 scripts.