[kepler-dev] Configuration

[Sean Riddle]

Is there any disadvantage to doing *at least* choice 3, and optionally  
choice 1 or 2 as well?

- Sean

On Nov 20, 2009, at 1:53 PM, Chad Berkley wrote:

> Hi,
>
> After looking at this a bit more, there are a few options for how to  
> do it.  There are tradeoffs for each.
>
> 1) store a module's alias(es) in module-info/aliases.txt
>   - pro: a module can have one or more aliases and define them itself
>   - con: conflicts may occur between modules because a module might  
> be unaware of another module's alias
>   - con (or pro): developer is responsible for setting an alias
> 2) have an alias list in the build-area/settings
>   - pro: centralized location for alias information
>   - con: devs would have to alter the build-area to add an alias
> 3) use a naming scheme to determine an alias.  For instance,  
> "common" would be a default alias for a module named "common-1.0.0rc1"
>   -pro: no list is kept or parsed.
>   -con: only one alias is allowed per module (might be a pro too)
>   -con: incorrectly named modules will need to be renamed or won't  
> work
>
> These are the three schemes I cam up with.  If you have any other  
> ideas, let me know.  I'm leaning toward #3 because I think it's  
> simple and does what we need without having to add more  
> configuration information.  I'll hold off on implementation until we  
> resolve this.
>
> chad
>
>
> Chad Berkley wrote:
>> Yeah, I'm working on it.  Hopefully I'll get it going today or  
>> tomorrow.  I'll let you know asap.
>> chad
>> David Welker wrote:
>>> Hi Chad,
>>>
>>> Sean Riddle mentioned that you were planning on changing the  
>>> configuration system so it does not refer to specific modules. Do  
>>> you know when this will be done? The kepler-1.1 branch does not  
>>> currently work, because the module "common" is referred to, when  
>>> what is available is "common-1.0."
>>>
>>> Is there anything I can do to help? I am pretty much stuck in  
>>> terms of publishing something that works until we get this to  
>>> work, because I am loathe to change the actual source code that  
>>> refers to specific module names in the kepler-1.1 branch unless it  
>>> is absolutely necessary, because this will continually complicate  
>>> any attempt to merge branches with the trunk, as will be  
>>> periodically necessary for patches.
>>>
>>> Thanks!
>>>
>>> David
>> _______________________________________________
>> Kepler-dev mailing list
>> Kepler-dev at kepler-project.org
>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev