You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ever since amboso turned into a thin script sourcing amboso_fn.sh (so >=1.9), I've been wondering if it was actually a good choice.
Having the script be a single file would allow for easier portability (avoiding the need to precisely locate the symbols to source), but it may come at a cost.
For now, the idea was that a globally-installed anvil would check the amboso-dir directory to source the local symbols.
This would be scrapped and the project compatibility would be checked by an explicit key in the stego.lock file (currently, it would be the anvil.version key).
This would break the existing link between the project-provided anvil and a system one
The text was updated successfully, but these errors were encountered:
jgabaut
changed the title
[FEATURE] Avoid resorting to file source as a means of ensuring portability
[FEATURE] Revert thin client change from 1.9
Aug 28, 2024
Ever since
amboso
turned into a thin script sourcingamboso_fn.sh
(so>=1.9
), I've been wondering if it was actually a good choice.Having the script be a single file would allow for easier portability (avoiding the need to precisely locate the symbols to source), but it may come at a cost.
For now, the idea was that a globally-installed
anvil
would check theamboso-dir
directory to source the local symbols.stego.lock
file (currently, it would be theanvil.version
key).anvil
and a system oneThe text was updated successfully, but these errors were encountered: