Installer

[Norbert Preining]

Hi Milan,

> As far as the directory goes, I just assumed nothing for the output
> directory, hence the path is just an alterable input. If all needs to be in
> one place, it can be adjusted as well but it is not a limitation of the
> software.

For sure, I don't think this is a serious problem and can easily be
adjusted.

> As far as the decompression goes, I am not entirely certain about the way
> it is done. As far as I can tell from the documentation and the source
> code, the tarfile package will refer to the lzma package for xz files. This
> however imports a LZMADecompressor that I do not find directly in the
> source code. I assume this is just a layer on top of C to support python
> calls to it. I just think that it is fast enough for this purpose as well
> as it is cross-platform.

Speed of the decompressor is less an issue, I guess. The question is
whether we need to ship/have available xz/xzdec as binaries somehow.
At the moment we ship xz/xzdec for most/all architectures to be sure we
can decompress our own packages.

> At the moment I think it is best if all the requirements for the package
> download were to be listed.

Not sure what you want to say with that.

> Correct me if I am wrong but the installer uses tlmgr, does it not?

No, it does not.
tlmgr and install-tl use the same functions from TeXLive::TLUtils, but
the installer does NOT use tlmgr.

I have thought about this and in case I find time I might implement it:
Install a minimal installation (like scheme-infra) and do all the rest
of the installation via tlmgr. But that is future talk, which hasn't
realized till now, mostly because the "features" or "expectations" of
install-tl and tlmgr are different. tlmgr needs to be able to revert to
old versions when installations fail, etc etc.

> If that were to be true I would only change the download portion of tlmgr
> by calling this downloader, leaving the logic intact. If that were to be
> the case only simpel download commands and responses can be given and
> returned by the program. Letting the logic of reverting back to the
> previous version be handled by tlmgr.

That would work for both install-tl and tlmgr, since both hook into
TeXLive::TLUtils. But parallelization is a different topic and much more
complicated.
I don't think that what you propose wrt tlmgr and reverting is easily
realizable, though.

I think the first task is speeding up install-tl, and see how we can
interface with a "special installer" like your python code based one.
After that, we can look into how to unify this approach over to tlmgr.
Again, future talk.

Now, if I only had the chance to quit my job and spend my time to do all this...

> If you would want to discuss this further, you can mail me or we could have
> a meeting.

Let us continue for now per email here on the list. If needs arrises, we
can surely arrange a video meeting (but be aware I am based in Japan JST
= UTC+9). There is also a IRC chat room on libera #texlive, although I
am the only one there (such an old style guy ...).

All the best

Norbert

--
PREINING Norbert                              https://www.preining.info
Mercari Inc.     +     IFMGA Guide     +     TU Wien     +     TeX Live
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13