Metacello related(?) MCFetchBitbucketRepository class>>#cacheDirectoryPath causes dNU when saving preferences

In a 5.3-19435 image with metacello loaded yesterday I just tried to save my preferences and caught an error.

Part of the saving process involves converting PragmaPreferences to saveable plain preferences and that in turn means finding the relevant value, which in the case of MCFetchBitbucketRepository means the cacheDirectoryPath. Sadly, the implementation is
^super cacheDirectoryPath
and no super class implements it. Boom.

The only implementation of #cacheDirectoryPath that has a definite value is in MCGitBasedNetworkRepository class>>#cacheDirectoryPath. Since MCBitbucketRepository is a subclass of this and would thus be happy, I suspect that MCFetchBitbucketRepository being a subclass of MCFilesystemFetchOnlyRepository implies that it should in turn implement a suitable version of #cacheDirectoryPath.

The whole MCFilesystemFetchOnlyRepository tree is dated fairly recently and commented as a new approach to decoupling some stuff, so I  would imagine that it simply hasn't been banged on enough to catch all this stuff yet. My guess is that a simple copy of the MCGitBasedNetworkRepository class>>#cacheDirectoryPath would work here - but I'm certainly not involved enough in metacello to be an authority. It 'works' in the sense that it allows saving my preferences but whether it would work for metacello operations... no idea.

I'll also note (since I have experience of it startling people on too many occasions) that MCGitBasedNetworkRepository keeps several repository cache values as class instance variables and the newer MCFilesystemFetchOnlyRepository class is keeping them as class variables. The difference can be important.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A bad random number generator:  1, 1, 1, 1, 1, 4.33e+67, 1, 1, 1

Thank you for the report Tim!

I addressed the issue here: https://github.com/Metacello/metacello/pull/526

Your assessment was correct: during the migration I missed the preferences accessors and the importance between ClassVars and class-side InstVars in this case was also lost. The above PR fixes both issues.

Best,
Tom
________________________________________
From: Squeak-dev <[hidden email]> on behalf of tim Rowledge <[hidden email]>
Sent: Friday, August 14, 2020 9:48:14 PM
To: The general-purpose Squeak developers list
Subject: [squeak-dev] Metacello related(?) MCFetchBitbucketRepository class>>#cacheDirectoryPath causes dNU when saving preferences

In a 5.3-19435 image with metacello loaded yesterday I just tried to save my preferences and caught an error.

Part of the saving process involves converting PragmaPreferences to saveable plain preferences and that in turn means finding the relevant value, which in the case of MCFetchBitbucketRepository means the cacheDirectoryPath. Sadly, the implementation is
^super cacheDirectoryPath
and no super class implements it. Boom.

The only implementation of #cacheDirectoryPath that has a definite value is in MCGitBasedNetworkRepository class>>#cacheDirectoryPath. Since MCBitbucketRepository is a subclass of this and would thus be happy, I suspect that MCFetchBitbucketRepository being a subclass of MCFilesystemFetchOnlyRepository implies that it should in turn implement a suitable version of #cacheDirectoryPath.

The whole MCFilesystemFetchOnlyRepository tree is dated fairly recently and commented as a new approach to decoupling some stuff, so I  would imagine that it simply hasn't been banged on enough to catch all this stuff yet. My guess is that a simple copy of the MCGitBasedNetworkRepository class>>#cacheDirectoryPath would work here - but I'm certainly not involved enough in metacello to be an authority. It 'works' in the sense that it allows saving my preferences but whether it would work for metacello operations... no idea.

I'll also note (since I have experience of it startling people on too many occasions) that MCGitBasedNetworkRepository keeps several repository cache values as class instance variables and the newer MCFilesystemFetchOnlyRepository class is keeping them as class variables. The difference can be important.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
A bad random number generator:  1, 1, 1, 1, 1, 4.33e+67, 1, 1, 1