From personal experience in the middle of a project at that time I also remember a few other problems with MKII ... besides I was having the impression that for each new MKII release that didn't solve a specific bug you'd have to adapt the original workaround.
depends, many parts are pretty stable but if you let a project depend on new features ...
Well, my feeling is some buggy parts weren't all that new at that time ...
understanding is that many Perl scripts have been superseded by Ruby scripts over time, still they're shipped with current MKII minimals.
i'm not ure what you mean here; we only keep perl scripts around for stuff that is not yet redone in ruby or because soem workflows may depend on it;
What I mean is that there is stuff lurking around in the minimals which is obsolete apart from rare (and presumably advanced) usage scenarios. However, this stuff makes trying to figure out the interdepencies of configuration files and variables quite a daunting task to say the least. For a suggestion on how to remedy this situation see my lines below.
Unfortunately there's no documentation about whether they could actually be deleted or whether there are still some (rare) tasks they're needed
depends on what kind of workflows one has; also some scripts are shipped that probably are used as pragma but since we use the same zips for updating i keep 'm there
Don't get me wrong but this is exactly the vague kind of answers I was referring to in my initial posting. As far as workflows are concerned my opinion is that keeping things *simple* should be the primary goal for any ConTeXt minimal distribution. One should agree on the simplest ConTeXt workflow possible and then design the minimals primarily with that idea in mind rather than trying to support each and every workflow under the sun right *out of the box*. The most common scenario will most probably be the average desktop user wanting to typeset a document interactively. That said, one could collect the legacy stuff you mentioned into a separate package for a start and clearly mark it as such. I think this should be feasible on all platforms ConTeXt runs on. The benefits of this approach abound: less scripts, less interdependencies to worry about, less environment variables, sleeker minimal distributions. Note that neither power nor flexibility would suffer: experienced TeX users will be able to tailor their minimals installation to meet the needs of an enterprise workflow anyway. If you need legacy stuff for old projects you extend the minimals with the appropriate component. If you need multiple ConTeXt trees within a web based workflow you put in those setuptex.tmf files and anything else that may be required. I hope this will clarify my point of view.
for. And then they seem to access dozens of environment variables and configuration files so you have no clue about whether those are needed or not. You just have to know. Which I don't.
it all depends on your local system ... in the minimals 'setuptex' just plays safe ... it sets up all variables that can interfere with an existing installation
If course, it depends on my local system. However, as a rule of thumb every installation of TeX (if there are several ones) should be responsible for not leaving behind any mess when it's not in use. Just my humble opinion how playing safe could be understood. Also, this is precisely what happens on a Mac when you have several versions of TeX Live, Fink-teTeX, MacPorts-teTeX etc. happily sitting side by side with zero effort on the user part ... Now this is my one and only motivation for getting rid of the shell script "setuptex" and the need for all those environment variables. There's really nothing more to all my questions about configuration files ...
Recently I had the chance to work on the Mac installer again and after some progress I got stuck at the very same vital point called configuration information and how it's accessed.
i wonder what configuration info you refer too; in a minimals setup there is only 'setuptex' and optionally one may want to adapt the cont-sys.tex file
I was referring to setuptex.sh setuptex.tmf context.cnf texmf.cnf environment variables and how the information contained therein is accessed (if at all) by the different engines and scripts.
Still I find the current situation rather frustrating ... in fairness I think this is also quite understandable from the above. Anyway, for the moment I'll stay put and wait for the configuration mechanism to stabilize. Once that has happened I'd be delighted to get to know the details about how it works ... then the Mac installer could also enter the stage finally.
as taco mentioned ... mkiv is for the brave ... we will cook up something that makes it usable for tex live but even then ... it will take a while
Honestly, to my ears this sounds like a contradiction. If you consider MKIV for the brave then why include it in TeX Live at all? Once I read that the ConTeXt shipping with TeX Live should be regarded as the official stable release ... Oliver