Namespacing repos

[stuartpb]

If I wanted to make it so only repos pushed to, say, paths under "apps/" get interpreted as app repos, how would I do that? (keeping the changes from plushu/plushu-git#9 in mind)

I think it would require alternate namespace-respecting versions of the apps/ and git-apps/ plugins.

Or perhaps this is an option that can be integrated into the main versions of the plugin? Maybe a hook?

A plugin can't be introduced to stand between other plugins in Plushu (well, except for if they return an error early in the cycle, which is kind of a sloppy / dangerous pattern, and one I'm not keen to invite.)

I was thinking about a hook that determines which hooks to run, but doy, we already have that - the repo hooks described in plushu/plushu-git#9 is what plugins listen on, then decide if they will run. I don't think it's worth hookifying that choice - that's the mouth of the rabbit hole down which madness lies.

Although, dang yeah a hook is the best way to introduce extensibility to saying whether or not the apps stuff should run, for introducing scopes and name rules and stuff. Letting people pick a plugin that introduces the right kind of scope for them is more flexible than, say, hard-coding the notion of prefixes (maybe the switching is based on the existence of a Procfile in the repo or something like that).

this is the point where I remember Plushu is supposed to support super-plugins

Maybe it can be like the idea for admin plugins - repo hook scoping can be handled by a plugin that encapsulates other plugins. You don't install the plugins as plugins, but as sub-plugins in this namespaced system.

(By "a plugin". I obviously mean a plugin for a specific kind of scope- multiple kinds of scope (one namespacing, one file-existence-switching) can be implemented by multiple plugins).

That's right, we do have a mechanism for letting plugins control other plugins, and it's explicitly dictating a hierarchy of interference in your design, the way it should be.

Of course you'd still need an an alternate version of plushu-git for namespacing the git-shell interface stuff. Which, yeah, that's a repo-specific question (recognizing the repo name needs to be tooled to the RPC architecture used to send names through that system). So that's cool by me. (And then you'd have git-apps installed alongside apps in this plushu-repos-namespaced namespacing subsystem that has plushu-git-namespaced as a sibling.)

[stuartpb]

I mean, hey technically you could do it with a plugin that self-polices like that - Plushu's flexible. But that's not a really extensible / sensible pattern, and its not one the "Plushu mainstream" looks to promote or propogate.

[stuartpb]

So hey, does this mean plushu-plugins-plugin should have "move" (reparent) and "copy" operations to add plugins into subplugin hierarchies? (Let's not go that far just yet - it's enough that plugins will have the ability to reuse the retrieval logic from plushu-plugins-plugin via hooks).

That may be called for with some crazy new plugin for that crazy management like plugins-meta:reparent. For now it's just something you log in as root / another shell user to manually do if you want that.

Especially since the only sensible way I could see those being implemented with proper extensibility is with commands so general they're just effectively aliases for $mv_or_cp $PLUSHU_ROOT/$2 $PLUSHU_ROOT/$3.

Maybe meta-plugins can have their own commands as relevant for stealing or copying currently-installed plugins.

[stuartpb]

I'm going to call these super-plugins and sub-plugins and note them in the glossary so it's clear that they actually are plugins that just don't get installed to the root plugin context.

Wait crap I'm going to need to change plushook since $PLUSHU_ROOT/plugins/ is currently hardcoded

[stuartpb]

Oh snap, does that mean I should change git-apps to not be master-branch sensitive, and then just let a namespacing plugin handle the master-branch scope stuff?

[stuartpb]

You wouldn't have an alternate git plugin, just a single other plugin alongside it that listens on all the hooks the Git plugin exposes, for its own namespacing (for instance, scoping things to only certain branches).

This also means you can have multiple types of namespace going on concurrently

Instances of this plugin could then be installed underneath repo-name scoping for multiple levels of passthrough. Oh snap, does that mean the starting dir needs to be a concatenative variable and not an argument?

Oh geez I never considered multiple instances of a superplugin as subplugins.

[stuartpb]

The key realizations from this were continued into plushu/plushu#37. Moving this back to backlog.

[stuartpb]

OK, so, coming back around to this, a legitimate purpose for this would be the use of, say, distinguishing dynamic app site repos from static files site repos.

Can those be accomplished by just setting / changing / checking a PLUSHU_APPS_REPO_DIR variable or something like that? Concatenating a PLUSHU_APPS_PREFIX, and not applying any plushu-apps plugin stuff if the repo that was updated doesn't live in that directory / prefix?

[stuartpb]

Wow, okay, this issue is old - I think it dates back to before there was a repos directory altogether, back when apps were just dumped straight into the home directory (which was how Dokku did it, and I still thought that Dokku made good design decisions).

So, yeah, this is definitely a function that should be internal to the design of the apps plugin as applicable - or, rather, to the plugins that tie apps to repos, plushu-app-repo-binding and plushu-git-apps. (Another thing that's improved in divergence from Dokku since this issue was originally filed: apps became potentially-freestanding siblings of repos rather than children.)

The question there becomes: should the change be part of the app's name, or around it? Can it be both? Is there a sensible way to put a conditional applier around, say, activating plushu-git-apps's hook(s), outside the plugin? (This seems like it comes back to the "super-plugin" idea.) It definitely doesn't seem like there's a clean way to wrap plushu-app-repo-binding to redefine its behavior: any conception of that change would need to come from within.

[stuartpb]

I feel like, as the considerations involved to do the deference for plushu-git-apps would be essentially only for that one plugin (since there aren't other plugins that do stuff based on Git activity, and whatever others may materialize, like git-link-new-repo-hooks, may not be appropriate to limit across such dimensionality), and there isn't really a clean design for plugins that live somewhere other than PLUSHU_PLUGINS_DIR, and I really don't know how you could make any kind of corresponding tweak for the app-repo-binding plugin... it's best to just introduce some shared conceptions of what can define conditions/constraints around app-to-repo bindings via config variables between the two plugins and stick to those conventions going forward. It definitely seems like the pattern I was originally imagining around "super-plugins" is not really materializing orthogonally enough for that to be a reproducible concept, as opposed to the multitude of ways that "a forked variant of the plugin that works fundamentally differently" is flourishing. (I was irritated with the unnecessary-feature-mismatching that came from Dokku going that way, the eight-different-kinds-of-MongoDB-plugin-that-each-broke-differently-due-to-bad-assumptions-and-unshared-feature-support, but that doesn't seem to be emerging as a problem at Plushu's level of plugin granularity, which, as a paramount design principle, has addressed that issue more directly).