Hi Chris,

On Thu, Jan 20, 2022 at 09:43:12PM -0600, Chris Muller wrote:
> Neat idea.  It should allow a slight reduction in complexity of
> deployment (one less file), while dodging that turn-off and deterrent
> for new users when they encounter the "missing sources" warning
> message.
>

Thanks for looking at it :-)
 
> I didn't look at the implementation, just the API, and would like to
> ask your thoughts about synchronicity with the .sources file.  Does
> the cached object know which .sources file (version) it is?

The cached object is nothing more than a read only copy of the
sources that does not require loading from disk. It is the simplest
possible hack that does not require actually hitting the file system
to read the sources.

The real sources file still needs to exist, if only for initializing
the in-image copy of it. But we don't need to read that file each
and every time we open the image.


> In case
> the .sources files is updated from the version the cached object is
> created from, and the user selects #clearCachedSources, what would
> happen?  Some way for the user to "update" their cached sources.
> 

clearCachedSources just clears a class variable so that you go
back to the normal behavior of loading source from the file system.


> I guess it should be fine since the .sources file is 100% static.  As
> long as the .sources file is the same as the cached object, the system
> can be toggled back even after a lot of work.  It's the .changes file
> that is continually updated, and this doesn't concern that file,
> right?

This is just for the sources file, not the changes file. It is a
minimal hack that supports the case of reading sources. I do not
expect it to work for a writeable stream such as the changes file.
And to be honest I would not want to implement that unless we
first had a reliable way to restore non-compressed sources from
a compressed sources stream (as far as I know that does not exist,
although I did not really look).

> 
> In any case, this is an improvement I hope we can squeeze into the
> next release.  Thanks for doing it!
> 

Thanks for you kind words, but I think we should discuss it after
the next release. The last thing I want to do right now is make
Marcel's release manager chores more complicated :-)

Meanwhile I'll be running it my own images just to make sure
that nothing horrible happens.

Dave