feisty meow cannot be easily installed system wide

[Fred T. Hamster]

the structure is totally inept for use by all users, since the production directory is right in the feisty code base folder! what if a normal user needs to rebuild?
=> that is a silly question. a user that wants to build would presumably have changed files first. so this bug should really mainly focus on (a) using feisty code in a system-wide install and (b) not polluting the source code hierarchy with generated files unnecessarily.

instead, we need to locate binaries in a safe place, like the temp dir.
=> this part has been completed. the code is now generated into a temporary folder by default. so that's most of part (b) of original motivation.

the build process should include an official coronation process for the
real owner, where he can build the production binaries into place
as expected right now [used to be, not any longer], but only he can run the step to do this successfully.
=> also sounds silly. we want the user, any user, to be able to be a packager of the feisty meow code and be able to produce a deb or rpm from it. if any user can do it, then it will be simple enough for me.

so, everyone else should still be able to use the binaries directory
locally; the local version should be the second default, if the official binaries dir doesn't exist.
=> this is a sensible idea; have a fallback default binary dir.
but it also brings in concerns again about how the scripts get generated to the same generated directory as the binaries.
*ha! which is a bogus concern, yes, since the script startups go into the loading dock. and have even when that had a different name. so, we do have good generated script vs. generated binary separation.
=> it almost seems to be implying that the script codebase and the built codebase should be way separate, as if the scripts could be installed via a separate deb/rpm, and the binaries only or binaries+source (or maybe totally separate binaries and source like most packages are done) could be installed.
=> this deserves to be pulled back out as a separate refactoring; splitting out the core feisty meow components as a separate package. would enforce a lot of cleaning and separation.
also not really worth it without lots of users having frustration over this. personally it doesn't bug me enough yet...

we also probably want an 'always local' mode for the binaries,
since then when a non-owner user rebuilds stuff, he'd not see any
changes!

hmmmmmm..... so maybe the best policy is actually that the binaries are always constructed per user.
a feisty install that was delivered with all the stuff prebuilt would be a neat thing too. that's what an image of the current build process might be able to use.

for now though, personal binaries sound best.,

=> overall seems more like (1) we want a super user to be able to update the binaries if desired, (2) we want a super user to be able to install the feisty meow package for all users if desired, and (3) we want individual users to be able to rebuild.
but are these each useful cases? how often does a non-root person want to rebuild things without changing the source (3)? and to change the source they need to have write access, so they could just check it out.

=> motivations stated initially do seem solid though (cases a and b).
case b is about separating out the storage of built binaries from code. that's pretty much done.
but case a in a sense is about bringing the binaries back in under the code hierarchy.
what about a presumed root hierarchy where all can live together, but support for separating out the scripts, source, and binaries as needed?
our previous support for case b really just moved most everything generated out, although we still need write access on the nucleus/library folder for the build config files.

partial answer:
we do already have FEISTY_MEOW_SCRIPTS as a variable. what about three modes for this (and any location variable): value defined externally (e.g. .bashrc), default value, and default fallback value?
if already set, but value is bad, we can either move up the chain automatically or complain about it. complaining and stopping seems right for the moment.
scripts var default=fmroot/scripts
default fallback... /usr/lib/feisty_meow/scripts

the defaults should be configurable at time of system-wide install also, so we can match the installers relocation requests.

so, then binaries dir and source code dir done similarly?
unfortunately there is no single source root! argh. feisty meow is split into multiple products: nucleus, octopi, graphiq, etc.
so, a single variable won't handle that.
but this also points to the fact that those products could be separately installed. nucleus is used by all (except kona, hmmm) so far, etc.
maybe it's also indicating that we could have a product variable for each one also. if it's different enough to be separate, doesn't it deserve it's own root folder variable? ugh.

[Fred T. Hamster]

consensus seems to be:
(i) fix feisty meow to be able to be used in a pre-generated form, such as a package or even a tar.gz.
(ii) we have enough separation of binaries for the moment; the generated feisty meow dir for binaries is the only thing we really need to make more portable.
(iii) our variable definition process would be way cooler if it supported multiple defaults (e.g. an array), and if each value was checked for usability before enshrining it. failures should be described, but maybe not stop things from working completely.
(iv) installer will need to ensure that each user gets the feisty meow startup/config process done for them automatically. this is new machinery, but it's not right to require the user to do something we can do automatically.
(v) installer needs proper dependencies, especially perl. Text::Diff and File::Which should be automatic. or we could use something else that's more complete or easier to get those tasks done in and rewrite the fm structure generating code.