If you’re working on package development and create a new version of a package (without changing the package name), copy it to the core/packages directory, and select "reinstall package," the new files are not copied by the file resolver.
I imagine this is by design, but I thought I’d raise the question of whether it should operate this way.
It’s somewhat inconvenient for the developer to have to remove the package each time to test a new version via the installer.
-
MODX Staff
- 10,725 Posts
We could definitely come up with a way to mark packages as "in development" (or similar) in the interface and have special handling for the package status in those cases, which is what is causing you trouble. This can all be handled at the transport package management level in MODx (i.e. no affect to the xPDO transport code).
However, it is by design. The expectation is that a package is a distributable release of something that if it changes, can be upgraded to a new version via a new package with validators and resolvers that are aware of any potential conflicts during upgrade. To be honest, I don’t create a package until I’m done developing something to a releasable point. Then I collect everything and test the package install. And in this fashion, to truly test installing a new instance of the same version of a package on the same MODx configuration, you would need to uninstall the package and/or otherwise return the configuration to it’s original state before the failed test.
Quote from: OpenGeek at Jan 27, 2009, 04:54 PM
However, it is by design. The expectation is that a package is a distributable release of something that if it changes, can be upgraded to a new version via a new package with validators and resolvers that are aware of any potential conflicts during upgrade. To be honest, I don’t create a package until I’m done developing something to a releasable point. Then I collect everything and test the package install.
Me too, but I often find problems with the install that didn’t show up earlier and sometimes it takes several iterations to get them ironed out.
And in this fashion, to truly test installing a new instance of the same version of a package on the same MODx configuration, you would need to uninstall the package and/or otherwise return the configuration to it’s original state before the failed test.
Agreed -- I ultimately have to do that, but not before I clear up the obvious install problems. I just thought that maybe a file resolver should default to overwriting any existing files of the same name on install or reinstall. I kept thinking it was a cache problem until I figured it out.
Is it the existence of the corresponding folder (named the same as the package .zip) that’s causing old files to be used?
Quote from: OpenGeek at Jan 27, 2009, 05:19 PM
Quote from: BobRay at Jan 27, 2009, 05:15 PM
Is it the existence of the corresponding folder (named the same as the package .zip) that’s causing old files to be used?
Partially yes; but I think it’s more directly the fact that no action is taken to re-extract the package contents because it is marked as installed.
Ah, . . . So the files *would* be overwritten on upgrade since the package name would be different?
I guess it makes sense that "reinstall" would just redo what was done the first time. I’m also guessing that the files *are* being overwritten now, but by files from the original package rather than ones in the replacement package.
The only reason it’s a particular pain now is that something’s wrong with my package and it doesn’t always uninstall properly.
