update command erroring
Description
Gliffy Diagrams
Activity
AJ Michels August 19, 2015 at 7:34 PM
Makes sense. Thanks Brad.
Brad Wood August 19, 2015 at 7:03 PM
Yeah, the idea is that CommandBox simply has everything needed under the hood to "just work". I use Git every day, but I don't actually have a general-purpose Git CLI installed. (GitHub for Desktop will open a CLI window for me, but there's no "git" binary in my system path). I lot of people may use Git but do so through a client and may or may not have the CLI binary in their system path. It's also just another annoying dependency for people to have to install. The majority of CF users are on Windows, and most of the ones that use Git use a GUI client, so we want to make it as easy as possible to just pick up CommandBox and make it work.
I've found JGit to be pretty responsive. I raised a bug the other day and it was patched in days. (It's an eclipse project, so not just a single developer shop or anything) Honestly, all we're using it for is some really basic Git commands like clone, etc so I highly doubt we'll hit any edge cases.
Actually implementing some basic forms of auth shouldn't be much work at all. I just didn't take the time to bother with it for now since I honestly didn't even know what percentage of people use private repos (as opposed to public GitHub repos). I'm glad to hear your feedback on SSH since I use that too and I'll probably toss in some support for it soon.
AJ Michels August 19, 2015 at 6:02 PM
I realize there is a bit of irony in me saying "married to the upgrade schedule of a third party library" while talking about a package management tool. But whenever I have encountered JGit in the past in particular, they have been very behind in the version of Git which they support.
AJ Michels August 19, 2015 at 5:52 PM
Hmm, that is unfortunate. Composer, Pip and NPM work so well and I think they just call out to the Git CLI. I could be wrong though. That is kind of the beauty of the "unix approach" of small programs that do specific things well. Plus they aren't married to the upgrade schedule of a third party library.
Would you say you are targeting users that are maybe not as comfortable with configuring Git and SSH? I know it was a pretty complicated process the first time I was introduced to it when I still used Windows. I suppose that would certainly position you ahead of other package managers in that respect.
Brad Wood August 19, 2015 at 5:01 PM
You would think it would be that easy We are actually using JGit-- a Java library for interacting with Git repos. This keeps CommandBox portable and consistent across platforms regardless of if the user even has a Git CLI installed. It supports pretty much all the same defaults as the native Git CLI, but there are also tons and tons of little customizations you can do-- like storing your private keys in a custom location. That's why I wanted to see if I should be worrying about all those possible non-standard setups, or just supporting the 'default' methods. User/pass has even more ways-- specified in the URL, prompt the user, stored in netrc, etc, etc.
The update command doesn't like dependencies from endpoints other than forgebox.
Enhance the endpoint interface so each endpoint can decide if there's an updated version of the package. Refactor the forgebox stuff into the forgebox endpoint.
Each endpoint now has a getUpdate() method that will behave as such:
ForgeBox - Get latest version from ForgeBox REST API and do semver compare
HTTP(S) - Always update
Git - Always udpate
Folder - Read box.json in folder and do semver compare
File - Read box.json in zip file and do semver compare