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
--
[EMAIL PROTECTED] mailing list
