Because the environment that thing is designed to regen is the development environment. That's not the environment you want to give to your users. This isn't so big a deal with things like web application servers, but it is very much a big deal with desktop applications.
It used to be, the way you deploy environments involved stripping out the parts you didn't need for your application. This is doable, but it is a pain, and if you do it wrong, your app blows up sometime when you don't expect. ObjectStudio Smalltalk can bootstrap itself from source files, so you can avoid stripping. VisualWorks tries to build itself up from components (Parcels) on a base image as a deployment strategy. These are less painful than stripping, but your app still blows up if you do them wrong.
Combine that with some vendors not being all that concerned about testing deployment, and you have a potential mess.
Image-based deployment done right - have two images. Your devlopment tools go in the second image. To deploy, you simply leave out the 2nd one.
Comments
So why does image-based development suck for deployment? If you can regen an environment from a simple text file what's the issue?
Because the environment that thing is designed to regen is the development environment. That's not the environment you want to give to your users. This isn't so big a deal with things like web application servers, but it is very much a big deal with desktop applications.
It used to be, the way you deploy environments involved stripping out the parts you didn't need for your application. This is doable, but it is a pain, and if you do it wrong, your app blows up sometime when you don't expect. ObjectStudio Smalltalk can bootstrap itself from source files, so you can avoid stripping. VisualWorks tries to build itself up from components (Parcels) on a base image as a deployment strategy. These are less painful than stripping, but your app still blows up if you do them wrong.
Combine that with some vendors not being all that concerned about testing deployment, and you have a potential mess.
Image-based deployment done right - have two images. Your devlopment tools go in the second image. To deploy, you simply leave out the 2nd one.
I imagine filtering out all the irrelevant lines from the changes log would be an issue if you went that route.