Re: Metacello packaging
Locked
 
|
(whew.... too long. if this keeps up, we'll have to wait until ESUG to
do this in person :) ) On Sat, May 29, 2010 at 9:36 PM, Dale Henrichs <[hidden email]> wrote: > > Julian Fitzell wrote: >> >> On Sat, May 29, 2010 at 12:32 AM, Dale Henrichs <[hidden email]> >> wrote: >>> >>> To directly answer your question...I agree, loading Grease should not >>> load >>> Slime by default and yes, Slime can certainly be in it's own Metacello >>> configuration (not package:). >> >> Looking at the Metacello chapter PDF that's circulating, it looks like >> what I meant was "project". Are you sure these things want their own >> configurations? It seems to me that Slime is "part of" Grease and all >> those other packages are "part of" Seaside, they're just not part of >> the core. Again, apologies if I'm just misunderstanding the >> terminology or the repercussions. > > Project and configuration are very similar in meaning, When I say > "configuration" I am specifically referring to a "ConfigurationOf package". > > In my opinion I think that "these things" do want their own configuration. > That is why I mentioned them:) However, the confguration vs group decisions > should be made by the developers themselves since that structure influences > how users of the configurations/groups view the project. > > From my perspective Slime is built on top of Grease rather than being a > fundamental part of Grease. Grease is supposed to be a portability layer > and Slime doesn't implement portability methods. Slime is a tool that is > used to analyze the portability of a body of code, but at the moment Slime > itself has not been ported to either Squeak or GemStone nor is it _required_ > for "Grease" functionality on the other platforms. > > So from that perspective Slime could be separated out into a separate > configuration without affecting the basic functionality of Grease as a > portability layer. I think Slime is quite fundamental to Grease from a developer's point of view. Because we can't reasonably test all valid behaviour, it's equally important to know the things you *can't* do. Would you feel differently if Slime was called Grease-Tests-Bad? That's how I think of it conceptually. >From the point of view of someone loading Grease as a compatibility layer for something they just want to run, though, clearly they don't need Slime. They might not even need the Grease tests, of course. I guess in my mind, for the average user choosing to load Grease, they should be getting Slime included on any platform that supports it. But there needs to be a slimmer set of packages (maybe it's just Grease-Core itself) that projects which use it can pull in. > In the end it is a judgment call as to when a chunk of functionality should > be split out separately, because in terms of pure functionality the > following two statements end up loading _exactly_ the same packages: > > ConfigurationOfSlime project latestVersion load. > > ConfigurationOfGrease project latestVersion load: 'Grease-Slime'. Agreed. > The factors that I think drive one towards choosing a configuration over a > group are: > > 1. how independent is the chunk of functionality? > - does the chunk of functionality have a utility outside of the > original project? > - does the chunk of functionality have an identity independent of > the original project? > - if either of the above are largely true, then a separate > configuration may be a good choice > 2. how critical is the chunk of functionality to the project? > - is it an option or an addon, where an "option" is something that > you have to choose one from many and an "addon" is something that > can be completely left off without affecting functionality? > 3. how heavy weight is the chunk of functionality? > - an addon that is complex in terms of the number of individual mcz > files or in terms of "required projects" may be easier to manage > if it is in its own configuration > 4. how tight is the coupling of the chunk of functionality? > - if the chunk of functionality is tightly coupled to the "core" > then it makes sense to embed the functionality in main > configuration And also, 5. how hard is it for people to know where to look for stuff? - if there are projects within a configuration you can look through the options - how do you know where to start looking for other configurations that might work with the one you're loading? And 6. how is the group of code branded? - if the combined functionality is considered to be distributed together, it may make sense to have it in a single configuration > I think that you went through a similar decision process when you originally > split Grease out from Seaside. > > In my opinion Slime should be separated out for points 1 (outside > functionality and independence), 2, and 3. In my world view, I think 1,2, and 3 actually argue for keeping Slime in the ConfigurationOfGrease. I can't see anyone using it without Grease, I think people should be loading it when working with grease, and its configuration is pretty simple, no? But that's just my image of it - I'm happy to hear alternate views. > For the Javascript chunks (Javascript, JQUery, Prototype and Scriptaculous) > I think the strongest arguments are points 2 and 3 ... I don't know about 4 > as for point 1, they don't have much utility outside of a Seaside context so > I would lean toward using a group with the caveat that point 3 could be a > reason for moving them all into a ConfigurationOfSeasideJavascript... > > RSS seem to me to be candidates because it is more like an addon. I mean, sure, I guess. But it's a single package, so why have a separate configuration? And I still worry about 5. Ok, let me put it another way: if it's an addon (and maybe it is), let's move it to the Addons repository (actually, I'm liking that idea). If we're bundling it by default in the Seaside distribution, I'd argue for keeping it in the same Configuration. > Comet could be called a group because of point 4. I guess I'd make the same argument as for RSS. > So the first order decision would be are any of those chunks candidates for > separate configurations or not ... in your opinion? I'm really just going on a gut feeling here, which is a dangerous place to be when I really don't know Metacello very well :). To me, if you have to namespace the configuration name (i.e. it's ConfigurationOfSeasideJavascript not ConfigurationOfJavascript) it feels a bit forced to have a separate configuration. "Seaside" to me is more or less what we distribute in the one-click, so in my opinion most of the stuff you mention should be in ConfigurationOfSeaside, due primarily to 1, 5, and 6. > What packages do you consider part of the Seaside-Base and where does > Seaside-Environment fit in? :) Ah... Environment. That wart keeps changing. Looking at the dependencies right now, we seem to be in a state where I would basically consider Environment plus its dependencies to be "Base". "Base" should be everything that basically everyone uses and nothing that opens ports, registers applications, or pulls in extra dependencies. So no Tests, no dev tools, no OB tools, no examples, no welcome screen, etc. Arguably Base should *not* include Environment itself, but let's not get too complex for now. So that's where I stand. I don't think my opinion is necessarily more relevant though: I certainly know the package structure well, but you know the packaging tool! And maybe a fear of multiplying Configurations is my own personal hangup. By the way, I changed the message subject and added seaside-dev - probably best to continue the discussion there rather than on the general seaside list. Julian _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Re: Metacello packaging
|
|
Julian Fitzell wrote: > (whew.... too long. if this keeps up, we'll have to wait until ESUG to > do this in person :) ) Haha, I think we're getting close. At this point I feel like I've made a case for splitting out the things that I thought could be split out and you are in favor of keeping them bundled ... your reasoning is sound and I don't think there is an absolute right and wrong here...my main purpose is to engage you in the decision making process and that has been accomplished, so I think we can leave the notion of breaking anything out into separate configurations behind us. > > On Sat, May 29, 2010 at 9:36 PM, Dale Henrichs <[hidden email]> wrote: >> Julian Fitzell wrote: >> From my perspective Slime is built on top of Grease rather than being a >> fundamental part of Grease. Grease is supposed to be a portability layer >> and Slime doesn't implement portability methods. Slime is a tool that is >> used to analyze the portability of a body of code, but at the moment Slime >> itself has not been ported to either Squeak or GemStone nor is it _required_ >> for "Grease" functionality on the other platforms. >> >> So from that perspective Slime could be separated out into a separate >> configuration without affecting the basic functionality of Grease as a >> portability layer. > > I think Slime is quite fundamental to Grease from a developer's point > of view. Because we can't reasonably test all valid behaviour, it's > equally important to know the things you *can't* do. Would you feel > differently if Slime was called Grease-Tests-Bad? That's how I think > of it conceptually. Haha, I don't feel any differently:), but I understand your point and that's the important part ... to you Slime and Grease are part of a single unit and _should_ be branded and treated together and that's enough of an argument for me. I think that with Doru's experience we do need to adjust the group definitions within Grease so that it is possible to load Grease without bringing in Slime .... So the questions become: 1. Should Slime be loaded by default when loading Grease? If no, we can split Slime out into a group that is not loaded by default. 2. Should Slime be loaded by default when loading Seaside3.0? If yes, that's easy to arrange. If no: Should Slime be included in one of the other Seaside3.0 groups like the development group _or_ do you want an independent Slime group so that Slime can be loaded "through ConfigurationOfSeaside30" _or_ do you expect someone to explicitly load Slime "through ConfigurationOfGrease"? > >> The factors that I think drive one towards choosing a configuration over a >> group are: >> >> 1. how independent is the chunk of functionality? >> - does the chunk of functionality have a utility outside of the >> original project? >> - does the chunk of functionality have an identity independent of >> the original project? >> - if either of the above are largely true, then a separate >> configuration may be a good choice >> 2. how critical is the chunk of functionality to the project? >> - is it an option or an addon, where an "option" is something that >> you have to choose one from many and an "addon" is something that >> can be completely left off without affecting functionality? >> 3. how heavy weight is the chunk of functionality? >> - an addon that is complex in terms of the number of individual mcz >> files or in terms of "required projects" may be easier to manage >> if it is in its own configuration >> 4. how tight is the coupling of the chunk of functionality? >> - if the chunk of functionality is tightly coupled to the "core" >> then it makes sense to embed the functionality in main >> configuration > > And also, 5. how hard is it for people to know where to look for stuff? > - if there are projects within a configuration you can look through the options > - how do you know where to start looking for other configurations > that might work with the one you're loading? > > And 6. how is the group of code branded? > - if the combined functionality is considered to be distributed > together, it may make sense to have it in a single configuration > Very good points! >> So the first order decision would be are any of those chunks candidates for >> separate configurations or not ... in your opinion? > > I'm really just going on a gut feeling here, which is a dangerous > place to be when I really don't know Metacello very well :). To me, if > you have to namespace the configuration name (i.e. it's > ConfigurationOfSeasideJavascript not ConfigurationOfJavascript) it > feels a bit forced to have a separate configuration. > > "Seaside" to me is more or less what we distribute in the one-click, > so in my opinion most of the stuff you mention should be in > ConfigurationOfSeaside, due primarily to 1, 5, and 6. > It will be easier to split things out later (if ever) than to glue them back together again, so going with your gut feeling is the prudent thing to do. >> What packages do you consider part of the Seaside-Base and where does >> Seaside-Environment fit in? > > :) Ah... Environment. That wart keeps changing. Looking at the > dependencies right now, we seem to be in a state where I would > basically consider Environment plus its dependencies to be "Base". > "Base" should be everything that basically everyone uses and nothing > that opens ports, registers applications, or pulls in extra > dependencies. So no Tests, no dev tools, no OB tools, no examples, no > welcome screen, etc. Arguably Base should *not* include Environment > itself, but let's not get too complex for now. Okay, I will take this (and your comments in earlier emails) as a starting point and flesh out the details and see if I run in to any questions or troubles and then we'll go from there...BTW, I plan to take a look at the initialization problems mentioned in separate e-mail... > > So that's where I stand. I don't think my opinion is necessarily more > relevant though: I certainly know the package structure well, but you > know the packaging tool! And maybe a fear of multiplying > Configurations is my own personal hangup. I think that by the time we've carved the Seaside packages up into groups, we should have a better feel for whether separate configurations are called for or not... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Re: Metacello packaging
|
|
On Sun, May 30, 2010 at 1:53 AM, Dale Henrichs <[hidden email]> wrote:
> > > Julian Fitzell wrote: >> >> (whew.... too long. if this keeps up, we'll have to wait until ESUG to >> do this in person :) ) > > Haha, I think we're getting close. > > At this point I feel like I've made a case for splitting out the things that > I thought could be split out and you are in favor of keeping them bundled > ... your reasoning is sound and I don't think there is an absolute right and > wrong here...my main purpose is to engage you in the decision making process > and that has been accomplished, so I think we can leave the notion of > breaking anything out into separate configurations behind us. Ok. >> On Sat, May 29, 2010 at 9:36 PM, Dale Henrichs <[hidden email]> > I think that with Doru's experience we do need to adjust the group > definitions within Grease so that it is possible to load Grease without > bringing in Slime .... > > So the questions become: > > 1. Should Slime be loaded by default when loading Grease? > > If no, we can split Slime out into a group that is not loaded > by default. I *think* that if you are explicitly loading Grease yourself, and your platform supports Slime, you should get Slime by default. > 2. Should Slime be loaded by default when loading Seaside3.0? > > If yes, that's easy to arrange. > > If no: > > Should Slime be included in one of the other Seaside3.0 groups > like the development group _or_ do you want an independent Slime > group so that Slime can be loaded "through > ConfigurationOfSeaside30" _or_ do you expect someone to explicitly > load Slime "through ConfigurationOfGrease"? No. There's a Seaside-Slime package in Seaside that adds Seaside-specific rules. It depends on having Slime and I guess should be in the Development group. Seaside-Core should depend on Grease-Core. Even if we had other Grease packages (-Filesystem, -Sockets, whatever) at some point in the future, I imagine applications might depend only the specific pieces they need. That minimizes the amount of stuff that has to be pulled in. Maybe we also want a Grease group that pulls in all the code but not the tests or Slime... not sure. Sound plausible? Julian _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Re: Metacello packaging
|
|
Julian Fitzell wrote:
> On Sun, May 30, 2010 at 1:53 AM, Dale Henrichs <[hidden email]> wrote: >> So the questions become: >> >> 1. Should Slime be loaded by default when loading Grease? >> >> If no, we can split Slime out into a group that is not loaded >> by default. > > I *think* that if you are explicitly loading Grease yourself, and your > platform supports Slime, you should get Slime by default. This is the current behavior. In the earlier discussions about Magritte, Grease and Slime you made the following statements: "The correct answer is that Grease should *not* load Slime by default" and "I still don't think that loading Grease should require you to load the refactoring engine." I'm not trying to incite a riot, but your current position seems to differ from your earlier statements. Given the confusion with Magritte and your statements below and your current intent I think the following groups make sense: 'Core' = #('Grease-Core') 'Core Tests' = #('Grease-Tests-Core') 'Slime' = #('Grease-Slime') 'Slime Tests' = #('Grease-Tests-Slime) 'Tests' = #('Core Tests' 'Slime Tests') 'default' = #('Slime') The expression: ConfigurationOfGrease project latestVersion load will load Slime and the Core. Seaside-Core in ConfigurationOfSeaside30 will specify a dependence upon the 'Core' group in Grease and Seaside-Slime will specify a dependence upon the 'Slime' group in Grease. Magritte-Model in CionfigurationOfMagritte2 will specify a dependence upon the 'Core' group in Grease only. I think this will make everyone happy. > >> 2. Should Slime be loaded by default when loading Seaside3.0? >> >> If yes, that's easy to arrange. >> >> If no: >> >> Should Slime be included in one of the other Seaside3.0 groups >> like the development group _or_ do you want an independent Slime >> group so that Slime can be loaded "through >> ConfigurationOfSeaside30" _or_ do you expect someone to explicitly >> load Slime "through ConfigurationOfGrease"? > > No. There's a Seaside-Slime package in Seaside that adds > Seaside-specific rules. It depends on having Slime and I guess should > be in the Development group. > > Seaside-Core should depend on Grease-Core. Even if we had other Grease > packages (-Filesystem, -Sockets, whatever) at some point in the > future, I imagine applications might depend only the specific pieces > they need. That minimizes the amount of stuff that has to be pulled > in. Maybe we also want a Grease group that pulls in all the code but > not the tests or Slime... not sure. > > Sound plausible? I think my suggestion above covers the Grease-related groups for Seaside. If the Grease groups make sense, then I think we can start focusing on the details of the Seaside-specific groups Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Re: Metacello packaging
|
|
On Wed, Jun 2, 2010 at 12:20 AM, Dale Henrichs <[hidden email]> wrote:
> Julian Fitzell wrote: >> >> On Sun, May 30, 2010 at 1:53 AM, Dale Henrichs <[hidden email]> >> wrote: >>> >>> So the questions become: >>> >>> 1. Should Slime be loaded by default when loading Grease? >>> >>> If no, we can split Slime out into a group that is not loaded >>> by default. >> >> I *think* that if you are explicitly loading Grease yourself, and your >> platform supports Slime, you should get Slime by default. > > This is the current behavior. > > In the earlier discussions about Magritte, Grease and Slime you made the > following statements: > > "The correct answer is that Grease should *not* load Slime by default" > > and > > "I still don't think that loading Grease should require you to load > the refactoring engine." > > I'm not trying to incite a riot, but your current position seems to differ > from your earlier statements. :) The confusion comes from the vagueness of my language, not that of my intent. In my earlier statements, I meant what you are calling "Grease Core". In my later statement I was referring to the configuration of Grease or the Grease project. > Given the confusion with Magritte and your statements below and your current > intent I think the following groups make sense: > > 'Core' = #('Grease-Core') > 'Core Tests' = #('Grease-Tests-Core') > 'Slime' = #('Grease-Slime') > 'Slime Tests' = #('Grease-Tests-Slime) > 'Tests' = #('Core Tests' 'Slime Tests') > 'default' = #('Slime') > > The expression: > > ConfigurationOfGrease project latestVersion load > > will load Slime and the Core. > > Seaside-Core in ConfigurationOfSeaside30 will specify a dependence upon the > 'Core' group in Grease and Seaside-Slime will specify a dependence upon the > 'Slime' group in Grease. > > Magritte-Model in CionfigurationOfMagritte2 will specify a dependence upon > the 'Core' group in Grease only. > > I think this will make everyone happy. This is exactly what I was hoping for (I think). Julian _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
Re: [Seaside] Re: Metacello packaging
|
|
Julian Fitzell wrote:
> On Wed, Jun 2, 2010 at 12:20 AM, Dale Henrichs <[hidden email]> wrote: >> Julian Fitzell wrote: >>> On Sun, May 30, 2010 at 1:53 AM, Dale Henrichs <[hidden email]> >>> wrote: >>>> So the questions become: >>>> >>>> 1. Should Slime be loaded by default when loading Grease? >>>> >>>> If no, we can split Slime out into a group that is not loaded >>>> by default. >>> I *think* that if you are explicitly loading Grease yourself, and your >>> platform supports Slime, you should get Slime by default. >> This is the current behavior. >> >> In the earlier discussions about Magritte, Grease and Slime you made the >> following statements: >> >> "The correct answer is that Grease should *not* load Slime by default" >> >> and >> >> "I still don't think that loading Grease should require you to load >> the refactoring engine." >> >> I'm not trying to incite a riot, but your current position seems to differ >> from your earlier statements. > > :) The confusion comes from the vagueness of my language, not that of > my intent. In my earlier statements, I meant what you are calling > "Grease Core". In my later statement I was referring to the > configuration of Grease or the Grease project. > >> Given the confusion with Magritte and your statements below and your current >> intent I think the following groups make sense: >> >> 'Core' = #('Grease-Core') >> 'Core Tests' = #('Grease-Tests-Core') >> 'Slime' = #('Grease-Slime') >> 'Slime Tests' = #('Grease-Tests-Slime) >> 'Tests' = #('Core Tests' 'Slime Tests') >> 'default' = #('Slime') >> >> The expression: >> >> ConfigurationOfGrease project latestVersion load >> >> will load Slime and the Core. >> >> Seaside-Core in ConfigurationOfSeaside30 will specify a dependence upon the >> 'Core' group in Grease and Seaside-Slime will specify a dependence upon the >> 'Slime' group in Grease. >> >> Magritte-Model in CionfigurationOfMagritte2 will specify a dependence upon >> the 'Core' group in Grease only. >> >> I think this will make everyone happy. > > This is exactly what I was hoping for (I think). > > Julian I think I suffer from "literal disease" ... where I apply "my definitions" to the words in "your sentences"...but in the end I agree that I think we are pretty close... Dale _______________________________________________ seaside-dev mailing list [hidden email] http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev |
«
Return to Seaside Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |