extra information in configurations

>
>
> On Sat, Apr 30, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
> Hi,
>
> Would it be possible to annotate an item in a configuration specification with some extra flags?
>
> For example, I have the following scenario:
> - I have ConfigurationOfMoose that includes ConfigurationOfFilesystem
> - Now, on Hudson, I want to run all tests specified in ConfigurationOfMoose and all included configurations, but I do not want to run those from Filesystem
>
> So why you want to load them then ?
> A configuration should have different groups, with and without tests.
> So..in your case why just NOT including the test is not enoguh ?  you want to include them but not to run it with Hudson ?

>  
> - Thus, I need to distinguish between the packages that are in Moose and those I depend on just loosely
>
> One idea would be to have something like this:
> spec project: 'Filesystem' with: [
>        ...
>        spec flagAt: #ignoreTests put: true ]
>
> Similarly, we could also have:
> spec package: 'XYZ' with: [
>        ...
>        spec flagAt: #someFlag put: #someValue ]
>
> What do you think?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Sometimes the best solution is not the best solution."
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

> Hi Mariano,
>
> On 30 Apr 2011, at 18:51, Mariano Martinez Peck wrote:
>
> >
> >
> > On Sat, Apr 30, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
> > Hi,
> >
> > Would it be possible to annotate an item in a configuration specification with some extra flags?
> >
> > For example, I have the following scenario:
> > - I have ConfigurationOfMoose that includes ConfigurationOfFilesystem
> > - Now, on Hudson, I want to run all tests specified in ConfigurationOfMoose and all included configurations, but I do not want to run those from Filesystem
> >
> > So why you want to load them then ?
> > A configuration should have different groups, with and without tests.
> > So..in your case why just NOT including the test is not enoguh ?  you want to include them but not to run it with Hudson ?
>
> This was just an example. There are several other scenarios in which I want to be able to distinguish between the essential parts of a system and the external dependencies. Or in which I want to label different parts in different ways.
>
> Given that the Configuration is already the place where I define the organization of my system, it would be the perfect place that could support other use cases beyond loading. So, this is why I proposed a simple solution for adding extra information in a simple dictionary.
>
> Cheers,
> Doru
>
>
> >  
> > - Thus, I need to distinguish between the packages that are in Moose and those I depend on just loosely
> >
> > One idea would be to have something like this:
> > spec project: 'Filesystem' with: [
> >        ...
> >        spec flagAt: #ignoreTests put: true ]
> >
> > Similarly, we could also have:
> > spec package: 'XYZ' with: [
> >        ...
> >        spec flagAt: #someFlag put: #someValue ]
> >
> > What do you think?
> >
> > Cheers,
> > Doru
> >
> > --
> > www.tudorgirba.com
> >
> > "Sometimes the best solution is not the best solution."
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
>
> --
> www.tudorgirba.com
>
> "Yesterday is a fact.
>  Tomorrow is a possibility.
>  Today is a challenge."
>
>
>

> I think you're trying to put so much responsibility on the
> Configuration. It is just a package management dependency, lets
> remember, so it should load only the packages it needs. This translates
> in that if you don't want the tests, then you don't load them to start
> with. If you need them loaded but not interacting, then that is another
> problem, maybe solved with another group in your configuration, one that
> only loads the non-test-groups it depends on.
>
> Cheers
>
> El sáb, 30-04-2011 a las 19:02 +0200, Tudor Girba escribió:
>> Hi Mariano,
>>
>> On 30 Apr 2011, at 18:51, Mariano Martinez Peck wrote:
>>
>>>
>>>
>>> On Sat, Apr 30, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
>>> Hi,
>>>
>>> Would it be possible to annotate an item in a configuration specification with some extra flags?
>>>
>>> For example, I have the following scenario:
>>> - I have ConfigurationOfMoose that includes ConfigurationOfFilesystem
>>> - Now, on Hudson, I want to run all tests specified in ConfigurationOfMoose and all included configurations, but I do not want to run those from Filesystem
>>>
>>> So why you want to load them then ?
>>> A configuration should have different groups, with and without tests.
>>> So..in your case why just NOT including the test is not enoguh ?  you want to include them but not to run it with Hudson ?
>>
>> This was just an example. There are several other scenarios in which I want to be able to distinguish between the essential parts of a system and the external dependencies. Or in which I want to label different parts in different ways.
>>
>> Given that the Configuration is already the place where I define the organization of my system, it would be the perfect place that could support other use cases beyond loading. So, this is why I proposed a simple solution for adding extra information in a simple dictionary.
>>
>> Cheers,
>> Doru
>>
>>
>>>
>>> - Thus, I need to distinguish between the packages that are in Moose and those I depend on just loosely
>>>
>>> One idea would be to have something like this:
>>> spec project: 'Filesystem' with: [
>>>       ...
>>>       spec flagAt: #ignoreTests put: true ]
>>>
>>> Similarly, we could also have:
>>> spec package: 'XYZ' with: [
>>>       ...
>>>       spec flagAt: #someFlag put: #someValue ]
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Sometimes the best solution is not the best solution."
>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Yesterday is a fact.
>> Tomorrow is a possibility.
>> Today is a challenge."
>>
>>
>>
>
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>

> I think you're trying to put so much responsibility on the
> Configuration. It is just a package management dependency, lets
> remember, so it should load only the packages it needs. This translates
> in that if you don't want the tests, then you don't load them to start
> with. If you need them loaded but not interacting, then that is another
> problem, maybe solved with another group in your configuration, one that
> only loads the non-test-groups it depends on.
>
> Cheers
>
> El sáb, 30-04-2011 a las 19:02 +0200, Tudor Girba escribió:
>> Hi Mariano,
>>
>> On 30 Apr 2011, at 18:51, Mariano Martinez Peck wrote:
>>
>>>
>>>
>>> On Sat, Apr 30, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
>>> Hi,
>>>
>>> Would it be possible to annotate an item in a configuration specification with some extra flags?
>>>
>>> For example, I have the following scenario:
>>> - I have ConfigurationOfMoose that includes ConfigurationOfFilesystem
>>> - Now, on Hudson, I want to run all tests specified in ConfigurationOfMoose and all included configurations, but I do not want to run those from Filesystem
>>>
>>> So why you want to load them then ?
>>> A configuration should have different groups, with and without tests.
>>> So..in your case why just NOT including the test is not enoguh ?  you want to include them but not to run it with Hudson ?
>>
>> This was just an example. There are several other scenarios in which I want to be able to distinguish between the essential parts of a system and the external dependencies. Or in which I want to label different parts in different ways.
>>
>> Given that the Configuration is already the place where I define the organization of my system, it would be the perfect place that could support other use cases beyond loading. So, this is why I proposed a simple solution for adding extra information in a simple dictionary.
>>
>> Cheers,
>> Doru
>>
>>
>>>
>>> - Thus, I need to distinguish between the packages that are in Moose and those I depend on just loosely
>>>
>>> One idea would be to have something like this:
>>> spec project: 'Filesystem' with: [
>>>       ...
>>>       spec flagAt: #ignoreTests put: true ]
>>>
>>> Similarly, we could also have:
>>> spec package: 'XYZ' with: [
>>>       ...
>>>       spec flagAt: #someFlag put: #someValue ]
>>>
>>> What do you think?
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Sometimes the best solution is not the best solution."
>>>
>>>
>>>
>>> --
>>> Mariano
>>> http://marianopeck.wordpress.com
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Yesterday is a fact.
>> Tomorrow is a possibility.
>> Today is a challenge."
>>
>>
>>
>
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>

> Hi,
>
> Indeed Metacello helps me describe my system and its dependencies, and indeed the first use case is to be able to load this description. Now, given that I already go through the trouble of describing the most important parts of my system, we could use this information for other use cases as well.
>
> It seems that providing an example made everyone pick on the example :). I am sure that even if you work in Pharo with all its core tests in the image, you do not want to run all Pharo tests all the time on your system. It is the same here. Sometimes I do want to run those external tests, sometimes not. For example, once a day I might want to run all tests, but for fast builds, I want to focus only on those that I work on.
>
> But running tests is not the only use case. I would also like to be able to have architectural constraints based on the very same information. Or to limit the scope of Lint rules.
>
> Actually, I would be interested in also being able to annotate the dependency relationships as well. Like this, we would have an extensible graph model that could be a cool platform for multiple tools with little effort.
>
> Cheers,
> Doru
>
>
> On 30 Apr 2011, at 19:33, Miguel Cobá wrote:
>
>> I think you're trying to put so much responsibility on the
>> Configuration. It is just a package management dependency, lets
>> remember, so it should load only the packages it needs. This translates
>> in that if you don't want the tests, then you don't load them to start
>> with. If you need them loaded but not interacting, then that is another
>> problem, maybe solved with another group in your configuration, one that
>> only loads the non-test-groups it depends on.
>>
>> Cheers
>>
>> El sáb, 30-04-2011 a las 19:02 +0200, Tudor Girba escribió:
>>> Hi Mariano,
>>>
>>> On 30 Apr 2011, at 18:51, Mariano Martinez Peck wrote:
>>>
>>>>
>>>>
>>>> On Sat, Apr 30, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> Would it be possible to annotate an item in a configuration specification with some extra flags?
>>>>
>>>> For example, I have the following scenario:
>>>> - I have ConfigurationOfMoose that includes ConfigurationOfFilesystem
>>>> - Now, on Hudson, I want to run all tests specified in ConfigurationOfMoose and all included configurations, but I do not want to run those from Filesystem
>>>>
>>>> So why you want to load them then ?
>>>> A configuration should have different groups, with and without tests.
>>>> So..in your case why just NOT including the test is not enoguh ?  you want to include them but not to run it with Hudson ?
>>>
>>> This was just an example. There are several other scenarios in which I want to be able to distinguish between the essential parts of a system and the external dependencies. Or in which I want to label different parts in different ways.
>>>
>>> Given that the Configuration is already the place where I define the organization of my system, it would be the perfect place that could support other use cases beyond loading. So, this is why I proposed a simple solution for adding extra information in a simple dictionary.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>>
>>>> - Thus, I need to distinguish between the packages that are in Moose and those I depend on just loosely
>>>>
>>>> One idea would be to have something like this:
>>>> spec project: 'Filesystem' with: [
>>>>      ...
>>>>      spec flagAt: #ignoreTests put: true ]
>>>>
>>>> Similarly, we could also have:
>>>> spec package: 'XYZ' with: [
>>>>      ...
>>>>      spec flagAt: #someFlag put: #someValue ]
>>>>
>>>> What do you think?
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Sometimes the best solution is not the best solution."
>>>>
>>>>
>>>>
>>>> --
>>>> Mariano
>>>> http://marianopeck.wordpress.com
>>>>
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "Yesterday is a fact.
>>> Tomorrow is a possibility.
>>> Today is a challenge."
>>>
>>>
>>>
>>
>> --
>> Miguel Cobá
>> http://twitter.com/MiguelCobaMtz
>> http://miguel.leugim.com.mx
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "It's not how it is, it is how we see it."
>

> Hi,
>
> Indeed Metacello helps me describe my system and its dependencies, and indeed the first use case is to be able to load this description. Now, given that I already go through the trouble of describing the most important parts of my system, we could use this information for other use cases as well.
>
> It seems that providing an example made everyone pick on the example :). I am sure that even if you work in Pharo with all its core tests in the image, you do not want to run all Pharo tests all the time on your system. It is the same here. Sometimes I do want to run those external tests, sometimes not. For example, once a day I might want to run all tests, but for fast builds, I want to focus only on those that I work on.
>
> But running tests is not the only use case. I would also like to be able to have architectural constraints based on the very same information. Or to limit the scope of Lint rules.
>
> Actually, I would be interested in also being able to annotate the dependency relationships as well. Like this, we would have an extensible graph model that could be a cool platform for multiple tools with little effort.
>
> Cheers,
> Doru
>
>
> On 30 Apr 2011, at 19:33, Miguel Cobá wrote:
>
> > I think you're trying to put so much responsibility on the
> > Configuration. It is just a package management dependency, lets
> > remember, so it should load only the packages it needs. This translates
> > in that if you don't want the tests, then you don't load them to start
> > with. If you need them loaded but not interacting, then that is another
> > problem, maybe solved with another group in your configuration, one that
> > only loads the non-test-groups it depends on.
> >
> > Cheers
> >
> > El sáb, 30-04-2011 a las 19:02 +0200, Tudor Girba escribió:
> >> Hi Mariano,
> >>
> >> On 30 Apr 2011, at 18:51, Mariano Martinez Peck wrote:
> >>
> >>>
> >>>
> >>> On Sat, Apr 30, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
> >>> Hi,
> >>>
> >>> Would it be possible to annotate an item in a configuration specification with some extra flags?
> >>>
> >>> For example, I have the following scenario:
> >>> - I have ConfigurationOfMoose that includes ConfigurationOfFilesystem
> >>> - Now, on Hudson, I want to run all tests specified in ConfigurationOfMoose and all included configurations, but I do not want to run those from Filesystem
> >>>
> >>> So why you want to load them then ?
> >>> A configuration should have different groups, with and without tests.
> >>> So..in your case why just NOT including the test is not enoguh ?  you want to include them but not to run it with Hudson ?
> >>
> >> This was just an example. There are several other scenarios in which I want to be able to distinguish between the essential parts of a system and the external dependencies. Or in which I want to label different parts in different ways.
> >>
> >> Given that the Configuration is already the place where I define the organization of my system, it would be the perfect place that could support other use cases beyond loading. So, this is why I proposed a simple solution for adding extra information in a simple dictionary.
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >>>
> >>> - Thus, I need to distinguish between the packages that are in Moose and those I depend on just loosely
> >>>
> >>> One idea would be to have something like this:
> >>> spec project: 'Filesystem' with: [
> >>>       ...
> >>>       spec flagAt: #ignoreTests put: true ]
> >>>
> >>> Similarly, we could also have:
> >>> spec package: 'XYZ' with: [
> >>>       ...
> >>>       spec flagAt: #someFlag put: #someValue ]
> >>>
> >>> What do you think?
> >>>
> >>> Cheers,
> >>> Doru
> >>>
> >>> --
> >>> www.tudorgirba.com
> >>>
> >>> "Sometimes the best solution is not the best solution."
> >>>
> >>>
> >>>
> >>> --
> >>> Mariano
> >>> http://marianopeck.wordpress.com
> >>>
> >>
> >> --
> >> www.tudorgirba.com
> >>
> >> "Yesterday is a fact.
> >> Tomorrow is a possibility.
> >> Today is a challenge."
> >>
> >>
> >>
> >
> > --
> > Miguel Cobá
> > http://twitter.com/MiguelCobaMtz
> > http://miguel.leugim.com.mx
> >
> >
> >
>
> --
> www.tudorgirba.com
>
> "It's not how it is, it is how we see it."
>

> But but, ...
>
> isn't metacello aimed on "end users"? Where has this been changed. The
> ultimate goal of Metacello is to install things. Of course, both you and
> Alexandre are pushing the limits of Metacello towards your own
> "development" style.
>
> I said, for end users, they only want to load Magma or Seaside, and no
> care about what thousand packages are needed to be installed first as
> dependencies. That is for me Metacello's raison d'être.
>
> With an analogy is like asking that apt in debian based linux distro's
> can be used for developers for everyday development. It is not. It is
> used only for releasing.
>
> Just my 2 cents :)
>
>
> El sáb, 30-04-2011 a las 21:56 +0200, Tudor Girba escribió:
>> Hi,
>>
>> Indeed Metacello helps me describe my system and its dependencies, and indeed the first use case is to be able to load this description. Now, given that I already go through the trouble of describing the most important parts of my system, we could use this information for other use cases as well.
>>
>> It seems that providing an example made everyone pick on the example :). I am sure that even if you work in Pharo with all its core tests in the image, you do not want to run all Pharo tests all the time on your system. It is the same here. Sometimes I do want to run those external tests, sometimes not. For example, once a day I might want to run all tests, but for fast builds, I want to focus only on those that I work on.
>>
>> But running tests is not the only use case. I would also like to be able to have architectural constraints based on the very same information. Or to limit the scope of Lint rules.
>>
>> Actually, I would be interested in also being able to annotate the dependency relationships as well. Like this, we would have an extensible graph model that could be a cool platform for multiple tools with little effort.
>>
>> Cheers,
>> Doru
>>
>>
>> On 30 Apr 2011, at 19:33, Miguel Cobá wrote:
>>
>>> I think you're trying to put so much responsibility on the
>>> Configuration. It is just a package management dependency, lets
>>> remember, so it should load only the packages it needs. This translates
>>> in that if you don't want the tests, then you don't load them to start
>>> with. If you need them loaded but not interacting, then that is another
>>> problem, maybe solved with another group in your configuration, one that
>>> only loads the non-test-groups it depends on.
>>>
>>> Cheers
>>>
>>> El sáb, 30-04-2011 a las 19:02 +0200, Tudor Girba escribió:
>>>> Hi Mariano,
>>>>
>>>> On 30 Apr 2011, at 18:51, Mariano Martinez Peck wrote:
>>>>
>>>>>
>>>>>
>>>>> On Sat, Apr 30, 2011 at 5:16 PM, Tudor Girba <[hidden email]> wrote:
>>>>> Hi,
>>>>>
>>>>> Would it be possible to annotate an item in a configuration specification with some extra flags?
>>>>>
>>>>> For example, I have the following scenario:
>>>>> - I have ConfigurationOfMoose that includes ConfigurationOfFilesystem
>>>>> - Now, on Hudson, I want to run all tests specified in ConfigurationOfMoose and all included configurations, but I do not want to run those from Filesystem
>>>>>
>>>>> So why you want to load them then ?
>>>>> A configuration should have different groups, with and without tests.
>>>>> So..in your case why just NOT including the test is not enoguh ?  you want to include them but not to run it with Hudson ?
>>>>
>>>> This was just an example. There are several other scenarios in which I want to be able to distinguish between the essential parts of a system and the external dependencies. Or in which I want to label different parts in different ways.
>>>>
>>>> Given that the Configuration is already the place where I define the organization of my system, it would be the perfect place that could support other use cases beyond loading. So, this is why I proposed a simple solution for adding extra information in a simple dictionary.
>>>>
>>>> Cheers,
>>>> Doru
>>>>
>>>>
>>>>>
>>>>> - Thus, I need to distinguish between the packages that are in Moose and those I depend on just loosely
>>>>>
>>>>> One idea would be to have something like this:
>>>>> spec project: 'Filesystem' with: [
>>>>>      ...
>>>>>      spec flagAt: #ignoreTests put: true ]
>>>>>
>>>>> Similarly, we could also have:
>>>>> spec package: 'XYZ' with: [
>>>>>      ...
>>>>>      spec flagAt: #someFlag put: #someValue ]
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Cheers,
>>>>> Doru
>>>>>
>>>>> --
>>>>> www.tudorgirba.com
>>>>>
>>>>> "Sometimes the best solution is not the best solution."
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Mariano
>>>>> http://marianopeck.wordpress.com
>>>>>
>>>>
>>>> --
>>>> www.tudorgirba.com
>>>>
>>>> "Yesterday is a fact.
>>>> Tomorrow is a possibility.
>>>> Today is a challenge."
>>>>
>>>>
>>>>
>>>
>>> --
>>> Miguel Cobá
>>> http://twitter.com/MiguelCobaMtz
>>> http://miguel.leugim.com.mx
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "It's not how it is, it is how we see it."
>>
>
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>