Hi everyone,
I want to propose that we clean up the current situation with the Zinc-Seaside package. While it may not be much of a problem when we run tests or talk about the default setup it becomes a real problem when your baseline loads both Seaside3 and ZincHTTPComponents. The problem partly lies with Metacello (I already talked to Dale about it), which calculates the packages to load for a project by also including all loaded packages from that project, even when that package is not part of the loading instruction for the project. That means, when I load Seaside3, which loads Zinc-Seaside, and then ZincHTTPComponents, Zinc-Seaside will be loaded again from ZincHTTPComponents because Zinc-Seaside already exists in the image. There's no way to solve this issue in the baseline (not even with fake dependency chains). From my point of view we, therefore, have two options: - rename Zinc-Seaside in the Seaside3 image to Seaside-Zinc. That would be good because it matches the Seaside prefix (I think we should do this anyway). This would also make it possible for the Zinc-Seaside package to remain in the Zinc project if we decide we want that. - delete Zinc-Seaside from the Zinc project (I think we should do this too), to avoid confusion. I talked to Sven two or three weeks ago and he thought that "ownership" of Zinc-Seaside currently resided with the Seaside project. So the question is, is there any reason to keep Zinc-Seaside in the Zinc project? Please let me know what you think. I'll be happy to provide the pull requests to both projects. Cheers, Max _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev signature.asc (849 bytes) Download Attachment |
Hey Max,
The Zinc-Seaside package is indeed moved to the Seaside project a while back: https://github.com/SeasideSt/Seaside/issues/1050 Do you have a sequence I can try to see what the problem still is? Renaming it is a good idea anyway. Cheers Johan
_______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
In reply to this post by Max Leske
> On 7 May 2020, at 09:07, Max Leske <[hidden email]> wrote: > > Hi everyone, > > I want to propose that we clean up the current situation with the Zinc-Seaside package. While it may not be much of a problem when we run tests or talk about the default setup it becomes a real problem when your baseline loads both Seaside3 and ZincHTTPComponents. > > The problem partly lies with Metacello (I already talked to Dale about it), which calculates the packages to load for a project by also including all loaded packages from that project, even when that package is not part of the > loading instruction for the project. That means, when I load Seaside3, which loads Zinc-Seaside, and then ZincHTTPComponents, Zinc-Seaside will be loaded again from ZincHTTPComponents because Zinc-Seaside already exists in the image. I seriously doubt that. Since Zinc-Seaside is *not* part of Zinc HTTP Components, I see no reason for it to be (re)loaded. If that does happen then there is a Metacello problem. (BTW: just to be 100% sure, we are talking about the latest GitHub versions). > There's no way to solve this issue in the baseline (not even with fake dependency chains). From my point of view we, therefore, have two options: > - rename Zinc-Seaside in the Seaside3 image to Seaside-Zinc. That would be good because it matches the Seaside prefix (I think we should do this anyway). This would also make it possible for the Zinc-Seaside package to remain in the Zinc project if we decide we want that. > - delete Zinc-Seaside from the Zinc project (I think we should do this too), to avoid confusion. > > I talked to Sven two or three weeks ago and he thought that "ownership" of Zinc-Seaside currently resided with the Seaside project. So the question is, is there any reason to keep Zinc-Seaside in the Zinc project? Regarding the name change: I am not necessarily against it, but it will confuse people even more than you are confused now. > Please let me know what you think. I'll be happy to provide the pull requests to both projects. > > > Cheers, > Max _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
On 7 May 2020, at 9:52, Sven Van Caekenberghe wrote:
>> On 7 May 2020, at 09:07, Max Leske <[hidden email]> wrote: >> >> Hi everyone, >> >> I want to propose that we clean up the current situation with the Zinc-Seaside package. While it may not be much of a problem when we run tests or talk about the default setup it becomes a real problem when your baseline loads both Seaside3 and ZincHTTPComponents. >> >> The problem partly lies with Metacello (I already talked to Dale about it), which calculates the packages to load for a project by also including all loaded packages from that project, even when that package is not part of the >> loading instruction for the project. That means, when I load Seaside3, which loads Zinc-Seaside, and then ZincHTTPComponents, Zinc-Seaside will be loaded again from ZincHTTPComponents because Zinc-Seaside already exists in the image. > > I seriously doubt that. Since Zinc-Seaside is *not* part of Zinc HTTP Components, I see no reason for it to be (re)loaded. If that does happen then there is a Metacello problem. > > (BTW: just to be 100% sure, we are talking about the latest GitHub versions). Actually that solve part of the problem. Zinc-Seaside is indeed no longer in the ZincHTTPComponents baseline on master (it is in v3.0.1). I can work with that. > >> There's no way to solve this issue in the baseline (not even with fake dependency chains). From my point of view we, therefore, have two options: >> - rename Zinc-Seaside in the Seaside3 image to Seaside-Zinc. That would be good because it matches the Seaside prefix (I think we should do this anyway). This would also make it possible for the Zinc-Seaside package to remain in the Zinc project if we decide we want that. >> - delete Zinc-Seaside from the Zinc project (I think we should do this too), to avoid confusion. >> >> I talked to Sven two or three weeks ago and he thought that "ownership" of Zinc-Seaside currently resided with the Seaside project. So the question is, is there any reason to keep Zinc-Seaside in the Zinc project? > > Regarding the name change: I am not necessarily against it, but it will confuse people even more than you are confused now. > >> Please let me know what you think. I'll be happy to provide the pull requests to both projects. >> >> >> Cheers, >> Max _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev signature.asc (849 bytes) Download Attachment |
In reply to this post by Johan Brichau-2
On 7 May 2020, at 9:13, Johan Brichau wrote:
> Hey Max, > > The Zinc-Seaside package is indeed moved to the Seaside project a while back: https://github.com/SeasideSt/Seaside/issues/1050 <https://github.com/SeasideSt/Seaside/issues/1050> > > Do you have a sequence I can try to see what the problem still is? See the mail from Sven and my response, I think we can consider the name clash when loading both baselines solved. This leaves the question of renaming the package. I think it is more natural to call the package Seaside-Zinc but I can also see Sven's point. Cheers, Max > > Renaming it is a good idea anyway. > > Cheers > Johan > >> On 7 May 2020, at 09:07, Max Leske <[hidden email]> wrote: >> >> Hi everyone, >> >> I want to propose that we clean up the current situation with the Zinc-Seaside package. While it may not be much of a problem when we run tests or talk about the default setup it becomes a real problem when your baseline loads both Seaside3 and ZincHTTPComponents. >> >> The problem partly lies with Metacello (I already talked to Dale about it), which calculates the packages to load for a project by also including all loaded packages from that project, even when that package is not part of the >> loading instruction for the project. That means, when I load Seaside3, which loads Zinc-Seaside, and then ZincHTTPComponents, Zinc-Seaside will be loaded again from ZincHTTPComponents because Zinc-Seaside already exists in the image. >> >> There's no way to solve this issue in the baseline (not even with fake dependency chains). From my point of view we, therefore, have two options: >> - rename Zinc-Seaside in the Seaside3 image to Seaside-Zinc. That would be good because it matches the Seaside prefix (I think we should do this anyway). This would also make it possible for the Zinc-Seaside package to remain in the Zinc project if we decide we want that. >> - delete Zinc-Seaside from the Zinc project (I think we should do this too), to avoid confusion. >> >> I talked to Sven two or three weeks ago and he thought that "ownership" of Zinc-Seaside currently resided with the Seaside project. So the question is, is there any reason to keep Zinc-Seaside in the Zinc project? >> >> >> Please let me know what you think. I'll be happy to provide the pull requests to both projects. >> >> >> Cheers, >> Max_______________________________________________ >> seaside-dev mailing list >> [hidden email] >> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > _______________________________________________ > seaside-dev mailing list > [hidden email] > http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev signature.asc (849 bytes) Download Attachment |
Free forum by Nabble | Edit this page |