[Cuis-dev] Saving a CodePackage and determining its class when installing it

[Juan Vuletich]

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.

Thanks,
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.
>
> Cheers!
> 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
>>     FakeCodePackage.
>>
>>     After poking around, I found this method in CodePackage that is
>>     used when saving an instance:
>>
>>     codePackageClass
>>       "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.
>>
>>     Cheers!
>>     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.
>
>     Thanks,
>
>     -- 
>     Juan Vuletich
>     www.cuis-smalltalk.org  <http://www.cuis-smalltalk.org>
>     https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
>     https://github.com/jvuletich
>     https://www.linkedin.com/in/juan-vuletich-75611b3
>     @JuanVuletich
>
>
>
> -- 
>
> Nicolás Papagna


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20201026/37540a3f/attachment.htm>