Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Include path #176

Open
anonymous1184 opened this issue Nov 27, 2022 · 2 comments
Open

Include path #176

anonymous1184 opened this issue Nov 27, 2022 · 2 comments

Comments

@anonymous1184
Copy link

The project looks really good.

Indeed, the AHK ecosystem is in need of a proper packaging system, however I find the end result for the include path cumbersome and tied to a specific repository.

#Include, %A_ScriptDir%\ahkpm-modules\github.com\joshuacc\simple-http\simple-http.ahk

What if I decide to use the same package/version from my own Gitea or Codeberg or whatever else? This will do regardless of the upstream:

; Option 1:
#Include, %A_ScriptDir%\ahkpm-modules\simple-http.ahk
; Optionally:
#Include, %A_ScriptDir%\ahkpm-modules\simple-http

It is easier to manage (and it doesn't even need the extension).

; Option 2:
#Include, %A_ScriptDir%\ahkpm-modules.ahk
; Optionally:
; #Include, %A_ScriptDir%\ahkpm-modules

This is even better as that file can contain all the packages with full paths.

The end user is presented with just a single line and that's a relief for many AHK users as the target audience is people that doesn't code.

Now, what about AHK v2? It was in alpha for like 10 years and in the past 3 quarters went from alpha to 15 betas to RC. Given that your project is written in Go, you can add compatibility regardless of what the users have installed. And is just the removal of the comma:

#Include, %A_ScriptDir%\ahkpm-modules.ahk
;       ^------ v1 compatible only

#Include %A_ScriptDir%\ahkpm-modules.ahk
;       ^------ v1/v2 compatible

; Optionally
#Include %A_ScriptDir%\ahkpm-modules

Anyway, that's just food for thought; perhaps if not by default it can be done via configuration or something.

Otherwise, is almost the same as using what's proposed by Chunjee. Which is not bad at all, then again is more focused on people with coding background (as it requieres Node.js, and people wanting simple AHK scripts don't have a fully bloated JS development environment):

yarn install PROJECT.ahk

Then:

#Include %A_ScriptDir%\node_modules\PROJECT.ahk\export.ahk
; or
#Include %A_ScriptDir%\node_modules
#Include PROJECT-1.ahk\export.ahk
#Include PROJECT-2.ahk\export.ahk
; ...
@SaifAqqad
Copy link
Contributor

The second option where an ahkpm-modules.ahk contains the rest of the includes is actually a really good idea, but this would mean that ahkpm install will need to add an include in the ahkpm-modules.ahk file and ahkpm needs to keep track of it.

Also I think we would need an ahkpm uninstall command to remove the package

BTW in the ahkpm-modules.ahk file, A_LineFIle could be used to reference it's own path

#Include %A_LineFile%\..\github.com\joshuacc\simple-http\simple-http.ahk

@joshuacc
Copy link
Owner

joshuacc commented Nov 27, 2022

The project looks really good.

Thanks!

What if I decide to use the same package/version from my own Gitea or Codeberg or whatever else? This will do regardless of the upstream:

; Option 1:
#Include, %A_ScriptDir%\ahkpm-modules\simple-http.ahk
; Optionally:
#Include, %A_ScriptDir%\ahkpm-modules\simple-http

It is easier to manage (and it doesn't even need the extension).

Unfortunately, I don't believe that will work, because fundamentally your copy of a package is a different package, where you are free to version and update entirely separately from the original. You could even rewrite the entire git history if you wanted to.

Because of this issue, ahkpm can't allow referring to different git repositories by the same name. Not only because it can potentially cause confusion. It could easily lead to security issues as well.

; Option 2:
#Include, %A_ScriptDir%\ahkpm-modules.ahk
; Optionally:
; #Include, %A_ScriptDir%\ahkpm-modules

This is even better as that file can contain all the packages with full paths.

The end user is presented with just a single line and that's a relief for many AHK users as the target audience is people that doesn't code.

This option may be viable. When working purely with packages that have an ahkpm.json file and a valid include path, this would probably work the vast majority of the time. Just automatically update the ahkpm-modules.ahk file with the includes whenver we run ahkpm install.

There are two scenarios where it gets more complicated.

  1. Packages that don't have a single main file to #Include, but allow
    including several different files.
  2. "Packages" that are just git repositories without an ahkpm.json.

The first one may or may not be a big deal, but I do think that it would be confusing to users that including ahkpm-modules.ahk usually includes all of their libraries, but not always.

The second one seems more problematic. Now, and for a while to come, most of the AHK packages that ahkpm can install will be plain git repositories without any ahkpm.json file at all. If they happen to only have a single *.ahk file in the repo, then we could automatically infer the proper include path. But what if it is more complicated? (As many of the existing GitHub repos are.)

At the very least, we would need to find a way to signal to the user that they need to handle those #Include's manually. And I don't have great ideas about how to do that yet.

Given that your project is written in Go, you can add compatibility regardless of what the users have installed. And is just the removal of the comma:

Yep! This is something I will definitely fix in the next couple of days. I've opened #180 to track it until then.

I was quite surprised when AutoHotkey 2 went into RC. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants