Re: [gentoo-catalyst] catalyst enhancement

[Ramon van Alteren]

Chris Gianelloni wrote:
> On Mon, 2007-04-23 at 14:02 +0200, Ramon van Alteren wrote:
>
>> To be clear, I'm willing to do all the work to get this implemented, I
>> already hacked up our current catalyst-2.0.1 install to do just this.
>> It is however rather hackish and i would like to get this in the main
>> tree. The patch would be against current svn.
>>
>> I'm curious about a number of things:
>>
>> * Would this functionality be useful for more people on the list ?
>>
>
> What is stopping you from using an absolute path on the machines?  If
> you control them, standardize on a checkout location.
>
To be honest, nothing, it's a nuisance or an itch that's driving this 
request not a necessity.
Most of us develop on laptops and commit code once it works, with 
deadline pressure as it is this tends to fuck up paths in the specfiles, 
which need to be reverted, yadadada.
Apart from that having the ability to checkout both devel- and 
production-branches  on the same buildmachine without the need to change 
the paths in the specfiles would be cool.
>> * Would this patch ever stand a chance of getting integrated ?
>>
>
> Not unless we can come up with some reason why we would need to add the
> code complexity to catalyst.  Essentially, there would have to be a few
> use cases that would absolutely prohibit using absolute paths, otherwise
> I don't see a reason for changing it.  This has been brought up before
> and always shot down simply because nobody could ever give me a reason
> why an absolute path wouldn't work for them and only a relative would.
> If you can show that what you want to do cannot be accomplished with the
> current code and absolute paths, then it would be accepted.

OK, clear enough.
I can't think of a use-case where absolute paths will not work and 
relative paths will, I have trouble finding such a use-case in general.
If that's the criteria then I guess it's a doomed enhancement request.

> Remember that simply making something easier for you isn't a valid reason for
> hacking up catalyst internals that much.
>
This puzzles me, if making a tool easier to use for it's users isn't a 
valid reason for hacking at the tool, then what is ?
I understand issues with code-quality, reluctance to touch internals and 
show me code before talk..........

It was a dual request, if nobody on list would be using the 
functionality I'll maintain a patch outside the tree for our benefit.
No sense in intergrating then.

Best regards,

Ramon
-- 
gentoo-catalyst@g.o mailing list