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
-----------------------------------------------------------------
_______________________________________________
dev-context mailing list
dev-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/dev-context
