GitHub Script Rewrite

[dargmuesli]

Instead of downloading a repository every time, the GitHub API is now used to determine if a new version exists. Possible version values are "", "latest", [version number], [branch name].

Please review and test.

[dargmuesli]

"a new version" stands for a GitHub release, that can be named anyhow, with its corresponding tag, which needs to be a valid PowerShell version number. In case no release exists the repository is downloaded as is like with the former script.

I will add some comments to the code and ensure that the version folders work.

[dargmuesli]

Currently the script only fetches the latest release (tag). I'll implement functionality for other versions.

[dargmuesli]

Seems pretty complete and functional now. I will test and bugfix extensively later.

And by the way: when is this going to make it into a release? This whole rewrite changes the functionality and backwards compatibility somewhat. What are your plans regarding that?

[dargmuesli]

As far as my testing and usage goes this is now functional and backwards compatible. I will add more improvements, when I find them.

Happy merging! :)

[RamblingCookieMonster]

Aie! Missed the notification for this. Will try to review in the next few days, but love the idea, existing workflow is definitely not efficient, thanks for working on this

Cheers!

[dargmuesli]

Hey @RamblingCookieMonster, have you had a look into this? It would be great if this got merged! Of course I'm open to change request and I'd like to help you solve issues with this if there are any. :)

[RamblingCookieMonster]

Eek completely forgot to revisit this! Have some free time over winter break, this is on the list : ) Sorry for the wait!

[dargmuesli]

How is it going? :D

[RamblingCookieMonster]

Arg! I'm bad : ) Playing with it now, looks good so far!

Down the line, might need to modify the way it calls Get-ProjectDetail - that function relies on the project root folder being the name of the project - I think other logic paths should still catch things for now though!

Should be able to merge this tomorrow, if not tonight

Cheers!

[RamblingCookieMonster]

Ahh! So it looks like we might run into issues for repos where tags aren't used, will poke around more tomorrow - Cheers!

[dargmuesli]

I didn't change the usage of Get-ProjectDetail from the original version of the GitHub PSDependScript. It's present like this in the current master version too. I've never looked at what it does specifically.

And regarding non-tagged repos: The current notation for the Requirements.psd1 is:

@{
    'dargmuesli/ps-docker-management' = @{
        "Version" = "master"
    }
}

This should work with the updated script too. Correct me, if I'm wrong. It's been a while since my last commit here ;) I'm here to help, as I'd really like to have this in a PSDepend release!

[RamblingCookieMonster]

Alrighty! I think I've narrowed it down to a few changes that I think would help (working on the first two now):

• Only use Target/Name/Version if PowerShell version supports it
• Add parameter to ignore Target/Name/Version and simply use Target/Name
• Up for debate - if this is a branch name, is it valuable to do Target/Name/Branch/Name? vs. Target/Name? How does PowerShell interpret these non-versioned paths?

Any concerns with this? Any thoughts on the last bullet? Haven't been in that scenario before, but figure you did this for a reason

Cheers!

[dargmuesli]

Good first two points! Regarding the third one: it was tricky to find out what PowerShell allows and what not. The current implementation allows multiple branches to be installed in parallel. Target/Name (obviously, because no Branch/ folder) wouldn't allow that. Are you sure you mean that folder structure?

[dargmuesli]

See my comments on #16 too.

[RamblingCookieMonster]

Ahh gotcha! So I like the idea of having the ability to install several versions in parallel, but I'd prefer to stick to what PowerShell will handle for default behavior - interestingly it will list the module if you Get-Module -ListAvailable, but it won't load it by name.

Have the following in place, would this work for you?

• Added TargetType parameter
  • Standard (Default) - If we can resolve a version (not branch), use Target/Name/Version. Otherwise, for branches, Target/Name - this is in line with PowerShell, even if it doesn't support side-by-side branch installs
  • Parallel - If we can resolve a version (not branch), use Target/Name/Version. Otherwise, for branches, Target/Name/Branch/Name
  • Exact - Don't resolve anything. Use Target exactly as is (e.g. if I want to drop a non-module folder or file in a particular folder - not all dependencies will be modules)

Also had a few minor tweaks in place:

• Import behavior will now import the $Destination if a module was installed (this helps allow importing item when using Parallel and Branch based dependencies)
• Test behavior now reflects specific version (i.e. if my dep. is version 1.0.0 and version 0.0.1 is installed, should return false). Have a little clean up to do on my end for testing branch based modules, that can wait.

Hit me up if you have any concerns, otherwise will tack the commit onto your branch for review!

Cheers!

[dargmuesli]

Approved. No concerns, good ideas!

[dargmuesli]

Otherwise the additions look good!

[RamblingCookieMonster]

Alrighty, a little over three months later, merging! Thanks for adding this, and sorry for the wait!

[dargmuesli]

Great, thank you! Someone once said "better late than never" :D If you need me to assist with any fixes or of you have additional questions, feel free to just ask :)