I just noticed that ConfigOfSmallDude declares an explicit dependency on two packages, Moose-Core and Famix-Core. I don't think it's good practice, as it could lead to conflict between a version of Moose and a version of SmallDude requiring different package versions.
-- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi Simon,
Hmm, but then I am not sure I understand how it could be done better. The goal of the Configuration is to allow one to load the code stand alone. So, SmallDude extends FAMIX and Group, so it needs Famix-Core and Moose-Core. Maybe we should rethink packaging? How would you do it? Cheers, Doru On 30 Mar 2010, at 00:10, Simon Denier wrote: > I just noticed that ConfigOfSmallDude declares an explicit > dependency on two packages, Moose-Core and Famix-Core. I don't think > it's good practice, as it could lead to conflict between a version > of Moose and a version of SmallDude requiring different package > versions. > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On 30 mars 2010, at 10:40, Tudor Girba wrote: > Hi Simon, > > Hmm, but then I am not sure I understand how it could be done better. The goal of the Configuration is to allow one to load the code stand alone. So, SmallDude extends FAMIX and Group, so it needs Famix-Core and Moose-Core. > > Maybe we should rethink packaging? How would you do it? I think the problem is that ConfigurationOfMoose plays two roles: managing the common parts of Moose and defining the Moose suite as common parts + projects. Maybe we should make this distinction clear with a ConfigurationOfMoose and ConfigurationOfMooseSuite? > > Cheers, > Doru > > > On 30 Mar 2010, at 00:10, Simon Denier wrote: > >> I just noticed that ConfigOfSmallDude declares an explicit dependency on two packages, Moose-Core and Famix-Core. I don't think it's good practice, as it could lead to conflict between a version of Moose and a version of SmallDude requiring different package versions. >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Hi Simon,
I was thinking of that as well, but the problem will still remain in that SmallDude might want one version of the configuration, and the Suite another one. Or? Cheers, Doru On 30 Mar 2010, at 12:52, Simon Denier wrote: > > On 30 mars 2010, at 10:40, Tudor Girba wrote: > >> Hi Simon, >> >> Hmm, but then I am not sure I understand how it could be done >> better. The goal of the Configuration is to allow one to load the >> code stand alone. So, SmallDude extends FAMIX and Group, so it >> needs Famix-Core and Moose-Core. >> >> Maybe we should rethink packaging? How would you do it? > > > I think the problem is that ConfigurationOfMoose plays two roles: > managing the common parts of Moose and defining the Moose suite as > common parts + projects. Maybe we should make this distinction clear > with a ConfigurationOfMoose and ConfigurationOfMooseSuite? > > >> >> Cheers, >> Doru >> >> >> On 30 Mar 2010, at 00:10, Simon Denier wrote: >> >>> I just noticed that ConfigOfSmallDude declares an explicit >>> dependency on two packages, Moose-Core and Famix-Core. I don't >>> think it's good practice, as it could lead to conflict between a >>> version of Moose and a version of SmallDude requiring different >>> package versions. >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> www.tudorgirba.com >> >> "Next time you see your life passing by, say 'hi' and get to know >> her." >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > Simon > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Every thing has its own flow." _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
On 30 mars 2010, at 13:15, Tudor Girba wrote: > Hi Simon, > > I was thinking of that as well, but the problem will still remain in that SmallDude might want one version of the configuration, and the Suite another one. Or? Well, if one produces a new version of Moose suite, one should check that he is using compatible versions from MooseCore and SmallDude. That is, if you want to make a version of MooseSuite4.0 using MooseCore4.0.1 and Smalldude2.0.3, I think it's good practice to check that Smalldude2.0.3 also uses MooseCore4.0.1. I agree that the problem is not solved, it is just merely passed upon the level of versions instead of packages (but maybe it is easier to notice/check such problems at version level). BTW, I think that given two versions of a package, Metacello resolves to load the latest one right? My current problem is that I am trying to build the tree of dirty packages recursively through projects, but if a package belongs to two projects, it's not clear what to do with this package. > > Cheers, > Doru > > > On 30 Mar 2010, at 12:52, Simon Denier wrote: > >> >> On 30 mars 2010, at 10:40, Tudor Girba wrote: >> >>> Hi Simon, >>> >>> Hmm, but then I am not sure I understand how it could be done better. The goal of the Configuration is to allow one to load the code stand alone. So, SmallDude extends FAMIX and Group, so it needs Famix-Core and Moose-Core. >>> >>> Maybe we should rethink packaging? How would you do it? >> >> >> I think the problem is that ConfigurationOfMoose plays two roles: managing the common parts of Moose and defining the Moose suite as common parts + projects. Maybe we should make this distinction clear with a ConfigurationOfMoose and ConfigurationOfMooseSuite? >> >> >>> >>> Cheers, >>> Doru >>> >>> >>> On 30 Mar 2010, at 00:10, Simon Denier wrote: >>> >>>> I just noticed that ConfigOfSmallDude declares an explicit dependency on two packages, Moose-Core and Famix-Core. I don't think it's good practice, as it could lead to conflict between a version of Moose and a version of SmallDude requiring different package versions. >>>> >>>> -- >>>> Simon >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Moose-dev mailing list >>>> [hidden email] >>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>> >>> -- >>> www.tudorgirba.com >>> >>> "Next time you see your life passing by, say 'hi' and get to know her." >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> [hidden email] >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> [hidden email] >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > www.tudorgirba.com > > "Every thing has its own flow." > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- Simon _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
Free forum by Nabble | Edit this page |