Add ability to install packages about gitify HOT 7 CLOSED

Also needs to support our modmore provider, somehow. Not sure how to get around the licenses unless people have an unlimited license and it can just use new ones all the time.

from gitify.

Packages should still be able to be installed and updated via package management, and then gitify-load should push its info (package + version number) back into .gitify.

gitify-build should auto-update and/or ask to update any packages that are newer in .gitify than in the modx installation.

from gitify.

We've been managing front-end packages in our projects using Bower, which uses the semver syntax which could work well for Gitify.

A developer could decide to install a package as a one-off e.g. Gitify install-package WayFinder=2.3.3 or save it to the config e.g. Gitify install-package WayFinder=2.3.3 --save

Then on build they could choose Gitify build --no-packages to exclude packages (package management would be on by default).

Other similar commands inspired by Bower could be used, e.g. Gitify uninstall-package WayFinder --preserve, following the standard MODX uninstillation process and updating the config; or Gitify list-packages, etc

With Bower you can also run Bower search package-name; if this is possible via the MODX Extras API (is there even an Extras API!?) then something like Gitify search-package GetPage which could then list available versions, etc.

Additionally the developer could get package update info via the command line, e.g. Gitify update-package would list updates, and Gitify update-package WayFinder would update the specific package.

The Gitify config file could look something like this:

package
    provider: modx.com: 
    service_url: http://rest.modx.com/extras/
    package: 
        - Ace : >1.5.0
        - FormIt : ~2.0.0
        - GetCache : >=1.1.0
        - GetResources : *
        - VersionX : >1.0 <2.0
        - WayFinder : =2.3.3
    provider: ModMore
    service_url: https://rest.modmore.com/
    username: myusername
    api_key: .gitify-packages
    package: 
        - ContentBlocks : >1.2.0

This would allow developers to each have different versions of plugins installed, but as long as it matches this branch's package version requirements then it would build Gitify.

If they change branch and a higher version package is required Gitify would go ahead and update accordingly with Gitify build is ran.

For the licence keys, this could go into a .gitify-packages file, which the main .gitify file could reference. This way the .gitify-packages could be ignored by git.

This file could then look like:

    provider: ModMore
        - api_key: mykey123

from gitify.

this would be a real time saver to setup the complete modx from cmdline. i like adams idea.

from gitify.

I'm wondering if it would be better to "hardcode" the installed package version, rather than specifying a minimum version, kind of what happens in the composer.lock file when using composer. That way Gitify build could attempt to force the specific version to be installed (that might not work across all providers; I'd have to double check but I don't think we expose old releases for modmore so it'll always get the latest instead).

Definitely in favour of Gitify install-package [package] [version] and perhaps Gitify update-package [package or empty for all]... searching should be possible too as package providers are APIs ;)

from gitify.

Would packages that have install-time configuration (i.e. ContentBlocks) have difficulties? or is there a way to handle that at the command line?

from gitify.

Setup options aren't really built to be handled from the command line (mostly it's plain HTML I believe: https://github.com/Mark-H/VersionX2/blob/master/_build/setup.options.php) but maybe it could try to analyse the html and ask interactive questions (like Gitify init does) for any it finds? Not sure, would need to research.

from gitify.