[Cuis-dev] Saving a CodePackage and determining its class when installing it
juan at jvuletich.org
Mon Oct 26 07:14:30 PDT 2020
Yes, same fix there. I just pushed it to GitHub. I hope that's all, but
if you find further trouble, please tell, and let's fix them.
On 10/26/2020 1:44 AM, Nicolás Papagna Maldonado via Cuis-dev wrote:
> Hi Juan,
> No worries! FakePackageClass is a hack until I have time to write some
> tests and be able to break the dependencies and inject Smalltalk and
> SystemOrganization into CodePackage instances, so these can be
> controlled from tests at will.
> I gave your fix a try but my package is still installed as an instance
> of FakeCodePackage.
> After some debugging, it looks like CodePackageFile>>install is
> checking whether any of the classes to be installed is a direct (just
> checks one level above) subclass of CodePackage, and uses it to
> create the code package.
> Here's an extract of that method that (I believe) exposes that behavior:
> *pckClass _ CodePackage*.
> classes do: [ :ee |
> (ee hasDefinition and: [*ee superclassName = 'CodePackage'*])
> ifTrue: [
> ee fileInDefinitionAndMetaclass.
> *pckClass _ Smalltalk at: ee name* ]].
> From what I understand, the method I mentioned in my previous email is
> used in the postPackageInstall phase, but this one happens before that.
> Should it be fixed too?
> Thanks for the help.
> Nico PM
> On Sun, Oct 25, 2020 at 9:24 PM Juan Vuletich <juan at jvuletich.org
> <mailto:juan at jvuletich.org>> wrote:
> On 10/25/2020 12:04 PM, Nicolás Papagna Maldonado via Cuis-dev wrote:
>> Hi Folks,
>> For some experiments I'm doing, I've created a subclass of
>> CodePackage (let's call it FakeCodePackage) to make my tests run
>> fast that avoids accessing Smalltalk or SystemOrganization.
>> When I filed-out the package and installed it in a fresh image,
>> to my surprise, the newly installed package was an instance of
>> After poking around, I found this method in CodePackage that is
>> used when saving an instance:
>> "Answer the specific CodePackage subclass to use."
>> self class == CodePackage ifFalse: [
>> ^ self class ].
>> self classesDo: [ :cls |
>> (cls inheritsFrom: CodePackage)
>> fTrue: [ ^ cls ]].
>> ^ nil
>> This means that whenever there is a subclass of CodePackage in
>> the package being saved, It is assumed that is the class that
>> should be used to re-creating the CodePackage instance when
>> installing it.
>> In my case, FakeCodePackage is not fully functional as I use it
>> only in my tests, so I was unable to either delete the package or
>> re-install it because of all sorts of errors.
>> Luckily this was a fresh image, so I had nothing to lose :)
>> I was wondering what is the use case for that, and if it still
>> relevant/in use.
>> Nico PM
> Too bad you found this bug. I hadn't thought of people writing
> subclasses of CodePackage, unless for instantiation of the package
> itself. This is used by ColorExtrasPackage and
> MorphicMisc1Package. It is only used to run #prePackageInstall and
> #postPackageInstall, and I don't think it is a clean solution.
> Anyway, I just posted a fix to that method, to also check for the
> package name.
> Juan Vuletich
> www.cuis-smalltalk.org <http://www.cuis-smalltalk.org>
> Nicolás Papagna
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cuis-dev