Q: should

box install

by default advise if its installation process of a given lib will steamroll any existing files? It probably should, shouldn't it?

Maybe as an option controlled by a flag

Well: yeah... I'd expect the option default to error out, and have a flag

--force=true

or something to flag up "yeah yeah, it's nae bother... steamroll away"

Depends on which files you mean. When updating a package of a lesser version to a greater version, the old package will be uninstalled (which is noted in the

--verbose

output), but IMO that's an expected behavior of any package manager. The code inside the package's installation folder is a black box subject to go away at any time if you ask the package manager to update the package.

Actually yeah, perhaps belay this line of enquiry entirely. The issue is not with what CommandBox does; the issue is with the dumb-arse way CFWheels projects are organised in the filesystem. Let's just pretend we never saw this thread, and move on with our lives.

Yes, CFWheels has a historical issue of merging the idea of • the core framework code (which you don't touch) • the application skeleton (which you turn into your app) The package on ForgeBox has historically contained both (though I think there's some effort to correct this) which sort of makes the installation a one-time gig for now.

Yeah that was my approach in the end. Use

box install cfwheels

to install it, then took it out of box.json. As you say, I think they need to split the concept of "deploy" (the app files in the

wheels

dir) and "install" (the skeleton files outside the

wheels

dir). I presume the

box install

process allows an app-specific installation process to be triggered after the files are grabbed from the repo? It would be that process that my question should be aimed at: "by default advise if its installation process of a given lib will steamroll any existing files"

Do you mean like a

postInstall

package script inside the package being installed that runs an arbitrary command after installation? There is nothing currently in place to mitigate the effects of that, though it would be easy to add dragons there...

Yeah something along those lines (reading from https://commandbox.ortusbooks.com/developing-for-commandbox/interceptors/core-interception-points/package-lifecycle#postinstall). It's be up to the installed package's handler to do the decision-making there. EG: wheels would know which files to sling into the adjacent directory, and also should know that the implementation might have changed some of them, so should check a hash or something on each file, and either ask whether to overwrite or not (or whatever). Anyway, that looks to be how they should organise themselves. I don't want to volunteer ppl for work, but it might be something for @Peter Amiri to consider / have on his radar.

@Adam Cameron and @bdw429s I started this process before leaving on vacation. The wheels generate app command and its wheels generate app-wizard counterpart use a scheme similar to ColdBox. There are new app templates that are installed and have a dependency on a CFWheels-core package that gets installed in its own directory. Future update would be easily done using the package management capabilities. Once I get back from vacation I will document this more and clean the old packages.