Allow to specify a custom repo for the local cache
terencode opened this issue · comments
It seems this tool only allow downgrading packages from the default local pacman repo.
However, if the user created a custom repo for say all the AUR packages, downgrade will not find the different package versions.
I'd like an option like downgrade --repo <repo-name>
EDIT: It seems you can use --pacman-conf
but it will only work if you have the repo configured in a separate pacman.d file, and it's not very convenient to use.
Can you try PACMAN_CACHE
?
% PACMAN_CACHE='/var/cache/pacman/pkg/ /var/cache/aur/pkg/' downgrade foo
Yup, that works, sorry.
Would it be suitable to make downgrade use all cache location by default?
I think that makes sense! Feel free to report that as a separate feature request (with example pacman.conf
and desired behavior, please). Or, ideally, a PR 😄
If we push through with this as a PR, it would be good if we could then pass PACMAN_CACHE
and PACMAN_LOG
as command-line options, just to ensure that all environmental variables have consistent command-line counterparts. This would be consistent with changes made in #96.
Also, if we want to expand to searching all possible cache locations, we could also consider adding the maximum depth in the find
command for cache search to be an adjustable command-line option, as package manager wrappers like yay
use a nested (non-open) structure in the cache directories for storing AUR tarballs. In that case, we would need a maxdepth of at least 2 to find the packages.
WDYT? I don't mind personally developing this in the next iteration(s) if it is of interest. Not sure what priority this would take with respect to our other two open issues #83 and #118.
If we push through with this as a PR, it would be good if we could then pass PACMAN_CACHE and PACMAN_LOG as command-line options, just to ensure that all environmental variables have consistent command-line counterparts.
If @terencode wishes to contribute, I'm comfortable with them just solving their immedate problem and us handling that aspect as a separate issue. In fact, it seems like a separate issue anyway. These should have command line flags (or not) regardless of us working on better defaults (this Issue).
Also, if we want to expand to searching all possible cache locations, we could also consider adding the maximum depth in the find command for cache search to be an adjustable command-line option
Is it possible just to increase or remove the current -maxdepth
? I don't even remember why it's there; is the default cache directory deeply nested with non-package files, such than a naive find
would be super slow?
I don't mind personally developing this in the next iteration(s) if it is of interest
Up to @terencode if they'd like to contribute. If not, go for it.
Not sure what priority this would take with respect to our other two open issues
I think I'm m going to configure Projects for this repo, now that we're getting more maintainers collaborating. We can slot things into a Backlog column to indicate priority and use assignment and an In-Progress column to indicate ongoing work. I don't have an opinion on priority between our current Issues, only that we have some clear approach to indicating it.
Is it possible just to increase or remove the current -maxdepth? I don't even remember why it's there; is the default cache directory deeply nested with non-package files, such than a naive find would be super slow?
If we specify the cache directory as /var/cache/pacman/pkg
, maxdepth
has little to no effect since all tarballs are laid out in that directory and are not nested deeper. So maxdepth
is probably unnecessary there.
For other cases, it might be necessary, especially if we want to search for cached packages where there are other large directories present. We can address this in a new issue.
@atreyasha feel free to contribute if you are motivated ;).
Would it be suitable to make downgrade use all cache location by default?
With #123, it should be possible to search more cache locations with varying file structures. For example:
$ downgrade --pacman-cache '/var/cache/' --maxdepth 3 foo bar
You can vary the --maxdepth
parameter based on how deep the tarballs are located relative to the supplied --pacman-cache
.
Very nice, thank you!
Ok I tested it and while it works well, I think it could benefit from a couple of improvements:
- Show current version of the packages you wish to downgrade
- Print for each package downgrade the database it came from (right now it only shows
local
but it would be better if instead we hadlocal/core
andlocal/community
etc.) - While it seems it picks up the
Cachedir
from /etc/pacman.conf, I still have to usepacman-cache
for it to find my packages - You have to be careful not to forget the '/' at the end of the path otherwise it does not work
- Can maxdepth default to 2 when
--pacman-cache
is used?
- Show current version of the packages you wish to downgrade
Hmm, so if the package you wish to downgrade is already installed, the current version is shown in the generated table with a +
symbol on the left-hand side. The -
symbol indicates that version was previously installled. No symbol indicates it was never installed.
- Print for each package downgrade the database it came from (right now it only shows
local
but it would be better if instead we hadlocal/core
andlocal/community
etc.)
Would be good to get views from @pbrisbin here. AFAIK, this could be possible by just querying via pacman
before the table printing. Although this could be problematic if AUR packages are present, meaning we would need to have some wrapper to verify that a package is indeed an AUR package -> which could entail adding more dependencies.
- While it seems it picks up the
Cachedir
from /etc/pacman.conf, I still have to usepacman-cache
for it to find my packages
I just tested this and it is possible to have the following lines in /etc/pacman.conf
:
CacheDir = /var/cache/pacman/pkg
CacheDir = /path/to/another/cache/dir
downgrade
should be able to read and search both. I tested this and it works on my local system. Although you might need to play with --maxdepth
if your other caches are structured differently in terms of depth.
- You have to be careful not to forget the '/' at the end of the path otherwise it does not work
In my case, with or without the trailing slash did not affect the search. Could you provide the command that did not work for you?
- Can maxdepth default to 2 when
--pacman-cache
is used?
Once again would be good to get views from @pbrisbin here. Maybe this issue of diverging defaults could be settled by having a downgrade.conf
configuration file?
@terencode if you require this as a default right away, maybe alias downgrade='downgrade --maxdepth 2'
could help for now?
Re-opening this issue as there could be some things to discuss still.
Hmm, so if the package you wish to downgrade is already installed, the current version is shown in the generated table with a + symbol on the left-hand side. The - symbol indicates that version was previously installled.
Ok that works, I would have just prefered masking it and having it on top so it's easier to compare versions.
I just tested this and it is possible to have the following lines in /etc/pacman.conf:
Indeed, but for me it does not pick up the second Cachedir
probably because it's on a separate file in the /etc/pacman.d
dir and I then include it to pacman.conf with Include =/etc/pacman.d/<db-name>
In my case, with or without the trailing slash did not affect the search. Could you provide the command that did not work for you?
downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>
says Unable to downgrade <pkgname>
but downgrade --pacman-cache ~/.cache/pacman/ --maxdepth 2 <pkgname>
works.
Once again would be good to get views from @pbrisbin here. Maybe this issue of diverging defaults could be settled by having a downgrade.conf configuration file?
A custom configuration file would be welcome indeed. I would think most user with a local repo would put its cache next to the pacman one but I might be wrong.
Here, I have ~/.cache/pacman/aur
and ~/.cache/pacman/pkg
.
@terencode if you require this as a default right away, maybe alias downgrade='downgrade --maxdepth 2' could help for now?
Yes that's a good enough workaround for when the Cachedir issue is fixed :)
I just tested this and it is possible to have the following lines in /etc/pacman.conf:
Indeed, but for me it does not pick up the second
Cachedir
probably because it's on a separate file in the/etc/pacman.d
dir and I then include it to pacman.conf withInclude =/etc/pacman.d/<db-name>
Ah I see. Yes, the current line to read from /etc/pacman.conf
is as follows:
https://github.com/pbrisbin/downgrade/blob/master/downgrade#L37
read_pacman_conf() { sed '/^#\?'"$1"' *= *\(.*\)$/!d; s//\1/' "$PACMAN_CONF"; }
In downgrade
, we only supply CacheDir
and LogFile
as $1
, so only those would be read and not any of the include's. This could be a good addition to deal with the include's.
In my case, with or without the trailing slash did not affect the search. Could you provide the command that did not work for you?
downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>
saysUnable to downgrade <pkgname>
butdowngrade --pacman-cache ~/.cache/pacman/ --maxdepth 2 <pkgname>
works.
Hmm, I am able to get search results for downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>
.
I know sometimes find
is not too happy with non-absolute paths such as with ~
. Are you able to get complete results with both of these?
$ downgrade --pacman-cache "/home/<user>/.cache/pacman" --maxdepth 2 <pkgname>
$ downgrade --pacman-cache "/home/<user>/.cache/pacman/" --maxdepth 2 <pkgname>
I know sometimes find is not too happy with non-absolute paths such as with ~. Are you able to get complete results with both of these?
Same behaviour as before unfortunately.
Just to summarize some main discussion points in this issue :
-
Modify
local
andremote
to something more specific likelocal (core)
,local (community)
etc. Could be problematic when dealing with AUR packages, which require a wrapper to verify if they are indeed AUR packages. -
Look into include's in
/etc/pacman.conf
and how we pick up other cache directories. -
Consider making a downgrade-specific configuration file to set defaults.
-
Check whether
downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>
or similar command without trailing slash on path fails for other users. @pbrisbin maybe you could test this on your system? -
Maybe we add a
--debug
command-line option todowngrade
which would be much more verbose with variable and array-printing. We could request users to run problematic commands with--debug
to identify locations of bugs.
@terencode for point 4, could you paste the output of bash -x downgrade --pacman-cache ~/.cache/pacman --maxdepth 2 <pkgname>
?
Sorry for my terse mobile reply, but it wanted to leave some thoughts until I can get back to my computer.
1- SGTM, though if the option is there to pass arbitrary cache directories, don't we need to show that (and deal with long lines)? We can't know the cache name all the time.
2- seems not worth the complexity. If someone were very serious about this feature, I'd encourage them to contribute a stand alone exe to pacman that reuses its own config code to resolve includes and print values (this could very well exist), then we could use that here
3- since every option has an env var, some export lines in bashrc is meant to be the config file. If one really wanted, they could put exports into a specific file and make a wrapper to source it and call downgrade to achieve the same.
4- I can investigate this week
5- I love me some good --debug :)
@atreyasha here you go:
+ . gettext.sh
++ test 'X\t' = 'X\t'
++ echo=echo
++ test -z ''
++ case "$0" in
+ : ''
+ : ''
+ : ''
+ : ''
+ '[' '' = 1 ']'
+ '[' '' = 1 ']'
+ '[' '' = 1 ']'
+ : pacman
+ : /etc/pacman.conf
++ uname -m
+ : x86_64
+ : https://archive.archlinux.org
+ : 1
+ : 1
+ : 0
+ : 1
+ declare -a terms
+ declare -a to_ignore
+ declare -a to_install
+ declare -a pacman_args
+ declare -a installed
+ declare current
+ (( !LIB ))
+ set -e
++ dirname downgrade
+ locale=./../share/locale
+ [[ -d ./../share/locale ]]
+ TEXTDOMAINDIR=/usr/share/locale
+ export TEXTDOMAIN=downgrade TEXTDOMAINDIR
+ TEXTDOMAIN=downgrade
+ cli --pacman-cache /home/terence/.cache/pacman --maxdepth 2 gnome-shell-extension-gsconnect-git
+ parse_options --pacman-cache /home/terence/.cache/pacman --maxdepth 2 gnome-shell-extension-gsconnect-git
+ [[ -n --pacman-cache ]]
+ case "$1" in
+ [[ -n /home/terence/.cache/pacman ]]
+ shift
+ PACMAN_CACHE=/home/terence/.cache/pacman
+ shift
+ [[ -n --maxdepth ]]
+ case "$1" in
+ [[ -n 2 ]]
+ shift
+ DOWNGRADE_MAXDEPTH=2
+ shift
+ [[ -n gnome-shell-extension-gsconnect-git ]]
+ case "$1" in
+ terms+=("$1")
+ shift
+ [[ -n '' ]]
+ (( !1 ))
+ (( DOWNGRADE_NOSUDO ))
+ type -p sudo
+ main gnome-shell-extension-gsconnect-git
+ local term candidates choice pkg exit_code=0
+ (( 1 ))
+ for term in "$@"
+ process_term gnome-shell-extension-gsconnect-git
+ local term=gnome-shell-extension-gsconnect-git name operator version candidates choice
+ read -r name operator version
++ sed -r 's/(.*[^<>=~])(<=|>=|<|>|=|=~)([^<>=~].*)/\1 \2 \3/g'
+ installed=($(previously_installed "$name"))
++ previously_installed gnome-shell-extension-gsconnect-git
+++ read_pacman_conf LogFile
+++ sed '/^#\?LogFile *= *\(.*\)$/!d; s//\1/' /etc/pacman.conf
++ : /var/log/pacman.log
++ : /var/log/pacman.log
++ sed '
/.*\(installed\|upgraded\) \(gnome-shell-extension-gsconnect-git\) (\(.* -> \)\?\([^)]*\))/!d
s//\2-\4/
' /var/log/pacman.log
++ currently_installed gnome-shell-extension-gsconnect-git
++ LC_ALL=C.UTF8
++ pacman -Qi gnome-shell-extension-gsconnect-git
++ awk -F ' : ' '
/^Name / { name=$2 };
/^Version / { version=$2 };
END { if (name != "") printf("%s-%s\n", name, version) }
'
+ current=gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1
+ candidates=($(search_packages "$name" | filter_packages "$name" "$operator" "$version" | sort_packages))
++ search_packages gnome-shell-extension-gsconnect-git
++ local name=gnome-shell-extension-gsconnect-git pkgfile_re index
++ pkgfile_re='gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
++ filter_packages gnome-shell-extension-gsconnect-git '' ''
++ sort_packages
++ index=https://archive.archlinux.org/packages/g/gnome-shell-extension-gsconnect-git/
++ (( DOWNGRADE_FROM_ALA ))
++ local name=gnome-shell-extension-gsconnect-git operator= version= pkg
++ read -r pkg
++ grep -Fv testing/
++ curl --fail --silent https://archive.archlinux.org/packages/g/gnome-shell-extension-gsconnect-git/
++ sed -E '
/.* href="(gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst))".*/!d;
s||https://archive.archlinux.org/packages/g/gnome-shell-extension-gsconnect-git/\1|g; s|\+| |g; s|%|\\x|g'
++ xargs -0 printf %b
++ awk 'BEGIN { FS="/"; OFS="|" } { print $NF, $0 }'
++ pacsort -f -t '|' -k 1
++ cut -d '|' -f 2-
++ (( DOWNGRADE_FROM_CACHE ))
++ : /home/terence/.cache/pacman
++ : /home/terence/.cache/pacman
++ find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
+ (( 0 == 1 ))
+ present_packages gnome-shell-extension-gsconnect-git
+ local i=1
+ local pkgname=gnome-shell-extension-gsconnect-git
+ shift
+ (( 0 ))
+ return 1
+ [[ -n '' ]]
+ eval_gettext 'Unable to downgrade $name'
+ gettext 'Unable to downgrade $name'
++ envsubst --variables 'Unable to downgrade $name'
+ export PATH name
+ envsubst 'Unable to downgrade $name'
Unable to downgrade gnome-shell-extension-gsconnect-git+ echo
+ return 1
+ exit_code=1
+ return 1
I tried to replicate your cache directory structure using a locally built tarball of gnome-shell-extension-gsconnect-git
, but was unable to reproduce the error.
++ find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
+ (( 0 == 1 ))
This part of the error message shows that find
was executed and no packages matching the regex were found. This is really the bottleneck here.
What are the outputs of the following commands?
ls -al /home/terence/.cache/pacman
find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
find /home/terence/.cache/pacman -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
find /home/terence/.cache/pacman/ -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64)\.pkg\.tar\.(gz|xz|zst)'
If this does not fix it, I won't bother you with more of these tests :) We can just wait till @pbrisbin tries to reproduce it.
ls -al /home/terence/.cache/pacman
lrwxrwxrwx 1 terence terence 21 17 juil. 2019 /home/terence/.cache/pacman -> /mnt/WDC/Cache/pacman
find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'
nothing
find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r4.gc480564e-1-any.pkg.tar.xz
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r6.g1f9ee60f-1-any.pkg.tar.xz
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1-any.pkg.tar.zst
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r5.gce2cf171-1-any.pkg.tar.zst
find /home/terence/.cache/pacman -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'
nothing
find /home/terence/.cache/pacman/ -maxdepth 4 -regextype posix-extended -regex '.*/gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r4.gc480564e-1-any.pkg.tar.xz
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r6.g1f9ee60f-1-any.pkg.tar.xz
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1-any.pkg.tar.zst
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r5.gce2cf171-1-any.pkg.tar.zst
find /home/terence/.cache/pacman -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'
nothing
find /home/terence/.cache/pacman/ -maxdepth 2 -regextype posix-extended -regex '.*gnome-shell-extension-gsconnect-git-[^-]+-[0-9.]+-(any|x86_64).pkg.tar.(gz|xz|zst)'
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r4.gc480564e-1-any.pkg.tar.xz
/home/terence/.cache/pacman/pkg/gnome-shell-extension-gsconnect-git-21.rc1.r6.g1f9ee60f-1-any.pkg.tar.xz
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r8.gaa2753fb-1-any.pkg.tar.zst
/home/terence/.cache/pacman/aur/gnome-shell-extension-gsconnect-git-38.r5.gce2cf171-1-any.pkg.tar.zst
lrwxrwxrwx 1 terence terence 21 17 juil. 2019 /home/terence/.cache/pacman -> /mnt/WDC/Cache/pacman
I can reproduce the error now, it has to do with the symlink to another directory. Seems like without the deliberate trailing slash at the end, find
does not search deeper into pacman
and just assumes it is a file. With the trailing slash, find
probes into the contents.
This is a good find. One rudimentary fix is to force post-pend a slash on all pacman caches, since extra slashes will not change the semantics. Alternatively, there could also be an option within find
to force searching symlinks.
We can add this as a fix in the upcoming release(s). Thanks @terencode!
Thanks for your perspicacity @atreyasha ;)
Thanks for your perspicacity @atreyasha ;)
Happy to be of use while stuck at home :D
To overcome this issue of following symlinks, we can prepend options -H
or -L
, for example find -H ...
or find -L ...
. Tested these and both worked. Maybe we could choose which option sounds better (and safer) for resolving such an issue. -H
sounds like a safer and more conservative option to me.
Also, can I label this issue as a bug?
-L Follow symbolic links. When find examines or prints information
about files, the information used shall be taken from the properties
of the file to which the link points, not from the link itself (un‐
less it is a broken symbolic link or find is unable to examine the
file to which the link points). Use of this option implies -noleaf.
If you later use the -P option, -noleaf will still be in effect. If
-L is in effect and find discovers a symbolic link to a subdirectory
during its search, the subdirectory pointed to by the symbolic link
will be searched.
When the -L option is in effect, the -type predicate will always
match against the type of the file that a symbolic link points to
rather than the link itself (unless the symbolic link is broken).
Actions that can cause symbolic links to become broken while find is
executing (for example -delete) can give rise to confusing behaviour.
Using -L causes the -lname and -ilname predicates always to return
false.
-H Do not follow symbolic links, except while processing the command
line arguments. When find examines or prints information about
files, the information used shall be taken from the properties of the
symbolic link itself. The only exception to this behaviour is when a
file specified on the command line is a symbolic link, and the link
can be resolved. For that situation, the information used is taken
from whatever the link points to (that is, the link is followed).
The information about the link itself is used as a fallback if the
file pointed to by the symbolic link cannot be examined. If -H is in
effect and one of the paths specified on the command line is a sym‐
bolic link to a directory, the contents of that directory will be ex‐
amined (though of course -maxdepth 0 would prevent this).
I'm not against post-pending a /
all the time, or adding -L
or -H
all the time. However, what if we replaced DOWNGRADE_MAXDEPTH
with DOWNGRADE_FIND_OPTIONS
(akin to PACMAN_OPTIONS
)? Then the user could decide the appropriate -maxdepth
and -L
or -H
settings for their use-case. By default, I think we would pass nothing special, which means we'd be removing -maxdepth
for default usage.
I'm not against post-pending a
/
all the time, or adding-L
or-H
all the time. However, what if we replacedDOWNGRADE_MAXDEPTH
withDOWNGRADE_FIND_OPTIONS
(akin toPACMAN_OPTIONS
)? Then the user could decide the appropriate-maxdepth
and-L
or-H
settings for their use-case. By default, I think we would pass nothing special, which means we'd be removing-maxdepth
for default usage.
Possible, but we might encounter some issues. Below is the usage syntax of find
:
SYNOPSIS
find [-H] [-L] [-P] [-D debugopts] [-Olevel] [starting-point...] [expres‐
sion]
This means we would actively have to split whichever options the user provides into the relevant categories and place them either before or after the [starting-point...]
. For example, --maxdepth N
has to be after the starting point and -H
has to be before the starting point. So maybe this might add more work for downgrade
.
Oh that's too bad. I agree it's not a useful idea, given that.
Main remaining points of this issue have been transferred to #133. Closing this issue.