-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
The second option where an Also I think we would need an BTW in the #Include %A_LineFile%\..\github.com\joshuacc\simple-http\simple-http.ahk |
Thanks!
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.
This option may be viable. When working purely with packages that have an There are two scenarios where it gets more complicated.
The first one may or may not be a big deal, but I do think that it would be confusing to users that including 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 At the very least, we would need to find a way to signal to the user that they need to handle those
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. :) |
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.
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:
It is easier to manage (and it doesn't even need the extension).
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:
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):
Then:
The text was updated successfully, but these errors were encountered: