Oliver Buerschaper wrote:
Well, my feeling is some buggy parts weren't all that new at that time ...
some stuff is 'experimental' and therefore 'buggy' by definition ... if only because there is no one and perfect solution in traditional tex ... which is why we started the luatex project in the transition to mkiv it means that parts of context have to be split in kii and mkiv code (a rather tricky thing btw) so if you have a workflow wher eyou cannot update regularly, you should stick to the museum versions that taco mentioned (which also means, stick to pdftex for a while) we expect to need another two years to get luatex and mkiv in a state that most interfaces are stable
What I mean is that there is stuff lurking around in the minimals which is obsolete apart from rare (and presumably advanced) usage scenarios.
probably, so best is to ignore anything that does not ring a bell; i made the minimal because i needed them in projects and then found out that users could benefit from them (after all, there are the regular distributions (norbert, akira and gerben took care of that) for those who want things out of a box)
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.
well, in the minimals there's only TEXMF (and TEXMFCNF) and TEXMFCACHE and all the rest is to prevent interference; all these are discussed in the TDS/KPSE documentation
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.
well, users only need texmfstart and texexec (unless they want to do tricky things like generating font metrics or manipulating graphics; this is described in docs on the web but not for average users)
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
as duncan said .. minimal is not the same as small, it's just a subset
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 would mean that i'd have to cook up additional stuff for myself and there is no time for that (unless someone pays me for it); if i cannot use the minimals myself, i cannot spend too much time on it
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.
it would not make a difference, the only legacy stuff is some ruby scripts and some styles; it has nothing to do with environment variables
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.
well, as said, having yet another subset would make my live misserable bit anyone is free to make yet another minimal-minimal; maybe someone only wants latin modern, etc etc
I hope this will clarify my point of view.
sure, but i just have no time for more variants
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 ...
you're over optimistic ... i just logged in on one of our servers ... controller-1:~ # set | grep -i TEX TEXINPUTS=:/root/.TeX:/usr/share/doc/.TeX:/usr/doc/.TeX tex | latex | pdflatex) e='!*.+(tex|TEX|texi|latex)' see what i mean? and i really didn't install anything tex on that machine (older machines have even more)
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 ...
what is the problem with running just one script to set up the system? after all, if you don't call setuptex, you still need to set up the path (and i never set up the path because i can have multiple tex trees)
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
all the same (there's also setuptex.bat) and the tmf file can be used when you run from an editor (in which case the --tree=... flag will look for that file)
context.cnf
an example fo what i use here; handy for users who want to know the mem values
texmf.cnf
always needed
environment variables
which ones? i never set any, since setuptex does it for me
and how the information contained therein is accessed (if at all) by the different engines and scripts.
ah ... that's another story ... for that you need to consult the tds documentation and the kpse/web2c documentation
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 ...
because there are brave tex live users and because luatex itself will be on tex live (used as scripting engine so be prepared for another kick out ruby/perl/bash round); we also need to 'proof that it's possible' -) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------