so you're arguing that we should write out the sticky files, even if the user doesn't ever want them interfering?
I'm not arguing at all. It's just when APACHE_TEST_NO_STICKY_PREFERENCES=1 and no arguments passed, the logic is broken. The program gets into a loop it can't break out of.
an endless loop? hmm, I hadn't seen that. _something_ definitely needs to be fixed, then.
the endless loop in the following way: you don't provide args and you tell the program not to use the previous config, so it starts interactive config, you answer the questions, it tries to save them, but APACHE_TEST_NO_STICKY_PREFERENCES=1 prevents it from saving them. the program restarts, and goes again into the same loop.
I've suggested a fix, if you don't like it, please suggest a different one.
ok
For example do not run interactive config if APACHE_TEST_NO_STICKY_PREFERENCES=1. But it's a pity, since we could suggest users this technique to override older saved config (in addition to -save).
well, I think I'd like to see some more intelligence with the sticky preferences option. for instance, I'd like to see a -remove option that removed all hints of sticky preferences, to avoid exactly the error-prone manual removal you mentioned in your last message.
I think you don't want it to be removed, you want it to be ignored. If it doesn't get on your way, why should you care if it's there or not.
If it's removed you have to configure it again, which is annoying. But sure, if you want to code -remove option that's fine. perhaps change -save to extend to -custom_config=[save|remove].
and you have a valid point - is there any way to override existing sticky preferences? IIRC that was my main problem with all of this, that the sticky preferences were too sticky for my needs. rather than abolish them altogether, it would be nice to have an -interactive option to force interactive configuration again (which would not be saved unless -save was specified).
That's how I coded it. Please see the documented logic. It's quite possible that I didn't take into account some things that you do, but it perfectly works for all my setups.
speaking of -save, I can't recall if that is the default, but if it is I
wonder if it should be.
it's the default if no config already saved. -save is really -override.
it might not be easier on end users to save the first time, but it might help them in the long run if things were not saved until explicitly given -save. what if the first time they run A-T it's against a development apache version? it's not exactly intuitive how to un-stick yourself, so being sticky by default (rather than on demand) might end up causing trouble down the line.
That's not the case with most of users. Most users will install mp2 which will save the config for them anyway (regardless of A-T), then they will run other modules against that. If the upgrade their server and A-T can't find it in the same location it has saved, it'll ignore that config.
As I said above -remove is a good idea, but I doubt it can be easily implemented correctly if at all. Unless you make it a separate path (i.e. remove and quit) you are complicating the already complex logic even more complex. That's because the custom config may get loaded from Makefile.PL or from the test suite itself. In fact that's exactly where it won't work - if you call -remove and it deletes system-wide file, you will still have it locally. Moreover it may require root perms. And you may have hidden @INCs which may kick in later...
I'd rather see a good test case of yours where things don't work as expected (i.e. custom config gets on the way of the explicit options) and get that fixed.
That's all said, I'm not disagreeing that we need an intuitive way to fix any stale custom configs. May be option -save should have a bit of overloading in it: ignore any custom configs, use the explicit options, passed via env vars, command line args or interactive config, and save them overriding the old configs. Which is similar to my idea of NO_READ in the previous post.
just some ideas.
Yeah, but we still have a problem to solve.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
