Improve forkability - Githubissues

stvnrlly commented 8 years ago

If "18f" was set during configuration instead of hardcoded, this utility would be more usable/forkable by non-18F entities.

stvnrlly commented 8 years ago

18F-specific content is also a big issue for forkability. For example, about_yml_generate is baked into the init script, but other organizations may not use that standard or wish to adopt it. Separating the subcommands into other repos could help, but seems more difficult to maintain.

emanuelfeld commented 8 years ago

Sub-issues:

[ ] create config file for script

stvnrlly commented 8 years ago

I thought about this a little more, and here's my current idea:

The initial install script should ask for the org name. Organizations can keep their specific orgwide flavors in a predictable location (for example, github.com/ORG/ORG-cli). That flavor could include a custom name for the script (because some orgs already have a command named after them) as well as additional commands. You'd also be able to set a specific URL instead of the predictable location.

The URL to check for updates would be saved in ~/.orgwide/ORG.conf. Other settings for scripts could also be saved there, or things like API keys. There should also be an orgwide-update command to pull any recent changes from the remote location. The user could also add more commands as ~/.orgwide/orgwide-whatever, which would be installed after the org's flavor scripts. There may be a way here to install multiple orgs' flavors.

Running the script without an org name could give you a few default commands. There's a question here of whether there should even be default commands, or if that would make org-specific orgwide-init scripts difficult to maintain.

stvnrlly commented 8 years ago

One potential way to allow defaults and flavors is to put the default scripts into a new repo and version everything. If your flavor scripts are behind the default scripts, it's an indicator to check for changes. The output would be something like:

$ 18f --version
orgwide-cli version 0.1
orgwide-scripts version 0.5
18f version 0.5.3 # indicating 3 revisions beyond the default

Something falling behind would be:

$ 18f --version
orgwide-cli version 0.1
orgwide-scripts version 0.6
18f version 0.5.3 # now no longer ahead

This is still fairly brittle, but at least has some transparency.

emanuelfeld commented 8 years ago

I say:

I'm concerned about ORG.conf getting out of date if it's set locally, but you allow orgwide update
Most of the functions I'm interested in (and think others at DCgov would want to use) are in init
Not sure I understand why versioning for an organization's scripts repo would reflect versioning of the defaults
No to defaults

stvnrlly commented 8 years ago

After some thought, I don't like how manual the process seems, and how hard it is to sanely update the basic scripts. I'm playing with getting more like a package manager, where you install orgwide and then can do orgwide install 18f, orgwide install dcgov, and/or orgwide install basic. The main repo would keep a list of the repos where each org keeps those scripts, which would allow homebrew-like tracking and upgrading.

With separate script repos, sharing improvements also seems easier.

emanuelfeld commented 8 years ago

So, it would do orgwide install ORG and orgwide update ORG?

stvnrlly commented 8 years ago

Yep, the former for sure and something like the latter.

emanuelfeld commented 8 years ago

You sure you want to sign up to maintain the list? :sweat_smile:

stvnrlly commented 8 years ago

I...have to think about that.

18F / 18f-scaffolding

Improve forkability #6