Using `tdsdirs`, `l3build uninstall` might remove the `TEXMFHOME/tex` directory
I was adding a l3build config for luadraw so running l3build install can install luadraw source files.
To keep its directory structure
.
├── doc
│ └── ...
└── files
├── extensions
│ └── # lua files
└── # lua files
, I found the tdsdirs config useful.
Using
tdsdirs = {files = "tex/lualatex/luadraw"}
works, but at first I tried with
tdsdirs = {files = "tex"}
and then a l3build install followed by l3build uninstall removes the whole TEXMFHOME/tex directory.
l3build uninstall should be safer at valid but not recommended tdsdirs settings. For example, never remove layer-1 and 2 sub-directories inside TEXMFHOME.
I can see what you are getting at, but that has to balance with other factors
uninstallreally needs to clean any 'stray' files, which might include ones no longer generated- We are not always installing into
TEXMFHOMEso can't be sure of the structure
I'm not sure there's a 'clean' way to know if an arbitrary pattern can be cleaned up or not. So perhaps we need some form of warning here?
So perhaps we need some form of warning here?
We can warn when installing files directly into TEXMFHOME/<subdir>.
Do empty directories must be removed? It only matters when trying to install a file whose name and full path is the same as an empty directory.
In some cases, the current implementation already leaves empty directories. For example, in pgf repo which sets
tdsdirs = {tex = "tex"}
$ git clone --depth=1 [email protected]:pgf-tikz/pgf.git
$ cd pgf
$ l3build install --texmfhome ../temp-texmf
$ l3build uninstall --texmfhome ../temp-texmf
$ tree ../temp-texmf
../temp-texmf
└── tex
├── context
│ └── third
│ └── pgf
├── generic
├── latex
│ └── pgf
└── plain
└── pgf
10 directories, 0 files
@muzimuzhi The approach taken by l3draw to empty directories will result in them existing but begin empty - getting things working cross-platform this was the sane way to go
The approach taken by
l3drawto empty directories will
You meant l3build rather than l3draw?
Why does l3build install into TEXMFHOME? I know it does, but I'm curious why this is desirable.
If it must do this, not deleting pre-existing files/directories seems a rather important thing to do. That is, it is much safer to not delete something which should be deleted than to delete something which shouldn't.
If l3build needs to ensure files/directories are removed, can't it avoid using a directory where users typically keep all kinds of custom code?
The idea of the install target is to allow someone with a development checkout to install the package/class/whatever so they can use it on their local system. The only place we can predict is both writable and searched by TeX is TEXMFHOME, so that has to be the standard installation location. Some people will have multiple things on their local search path, but that's not at all predictable.
Uninstall doesn't happen that often, so you could perhaps implement the uninstall as a dry run using tree to display what would be removed and then asking interactively if that is intended and if the answer is not "yes" then abort with a message to please uninstall manually. That wouldn't prevent someone from making the wrong choice initially, but whether something is right or wrong as a value for tdsdirs isn't so clear cut.
I'm constantly installing and uninstalling packages. So getting a prompt every time would be a bit of a nuisance.
But I also did set TEXMFHOME to a special tree gitinstall which is only used for such installations, so if it gets deleted there is no harm done. Could we perhaps add (as once discussed here https://github.com/latex3/l3build/issues/125#issuecomment-979228531) a specific environment variable which allows to set the install tree and which then does not trigger such a prompt?
I'm constantly installing and uninstalling packages. So getting a prompt every time would be a bit of a nuisance.
but a fairly minimal one, I would think. Basically you go
l3build uninstall <enter> yes <enter>
or
echo yes | l3build uninstall <enter>
if you know that it is harmless.
But I also did set TEXMFHOME to a special tree
gitinstallwhich is only used for such installations, so if it gets deleted there is no harm done. Could we perhaps add (as once discussed here #125 (comment)) a specific environment variable which allows to set the install tree and which then does not trigger such a prompt?
but that might be a good compromize too
Uninstall doesn't happen that often, so you could perhaps implement the uninstall as a dry run using
treeto display what would be removed and then asking interactively if that is intended and if the answer is not "yes" then abort with a message to please uninstall manually.
The prompt can skip these cases:
- when uninstalling files in a module/bundle-specific subdirectory like
TEXMFHOME/tex/latex/<module-or-bundle>orTEXMFHOME/tex/context/third/<module-or-bundle>;
- when removing files which would be installed by
l3build installand when removing empty directories.
* when removing files which would be installed by `l3build install` and when removing empty directories.
The problem there is that we can't know that the current list of files to install is the same as the list of files which were installed and must be removed, e.g. if someone edits their .ins file. Now, I see that you can argue the same about the target directory, but that's a much less common issue (particularly for the standard case of tex/latex/pkg as the target).
Uninstall doesn't happen that often, so you could perhaps implement the uninstall as a dry run using
treeto display what would be removed and then asking interactively if that is intended and if the answer is not "yes" then abort with a message to please uninstall manually. That wouldn't prevent someone from making the wrong choice initially, but whether something is right or wrong as a value fortdsdirsisn't so clear cut.
I guess my worry there is we already have a --dry-run option, and that applies (or at least should apply) equally to install and uninstall, i.e. if you want to be careful, you can always dry-run first to see what will change.
Back on the original point of the report, that we likely need to fix independent of any other changes - it's clearly wrong.
The other issue with a warning is of course it doesn't help in the original situation: there's no easy/safe way to clean up if the settings include tdsdirs = {files = "tex"} or similar. Saying 'oh, clean up will delete all these files' doesn't really do much - we might be better simply skipping with a warning like
Cannot clean up files: TDS path too general
if we are given only a one-level path (or perhaps even a two-level one?).
I guess my worry there is we already have a
--dry-runoption, and that applies (or at least should apply) equally toinstallanduninstall, i.e. if you want to be careful, you can always dry-run first to see what will change.
that's not quite the same, here forcing the try run is more or less appropriate and better than telling somebody, "oh you could have been moe careful by first running a dry-run :-)
we might be better simply skipping with a warning like
Yes, I think that would be good. And I would say two-level.