Closed atreyasha closed 2 years ago
Apologies for the late response.
One high-level thought I had is that we're extracting a new (smaller, simpler) executable here, but we're still doing a lot of the "noisy" things we do in downgrade that were specifically necessary because of its higher level of complexity. WDYT?
That's true, I initially just modeled the syntax and flow in pacignore
from that of downgrade
and did not put too much thought into simplicity. But I agree, ultimately we are working towards making things "simpler" and what you mentioned is indeed a step towards that.
Let me know your thoughts on the changes made in this direction
Checklist
Description
This PR aims to integrate
pacignore
intodowngrade
as discussed previously. So far I did the following:downgrade
andpacignore
scripts into dedicatedbin
directoryMakefile
to install both scripts given new locationspacignore
as discussed previously@pbrisbin WDYT about the diffs so far?
Next steps
Besides the usual housekeeping tasks in the checklist above, I want to add the following features in this PR:
~1. Add an
includes
subcommand topacignore
to check if a package is currently being ignored, for examplepacignore includes foo
to check iffoo
is currently being ignored. This feature would simplify theprompt_to_ignore
function in thedowngrade
script and would reduce some boilerplate code in thepacignore
script.~pacignore
invocations inside theprompt_to_ignore
function in thedowngrade
scriptrestyled
to also checkpacignore
Regarding implementing point 1 above, I plan to change the
prompt_to_ignore
function to the following:I tested this locally and it works fine with a system-level install. However, I am not sure how to make this work successfully for the unit tests. This is because the current unit tests source functions from
downgrade
andpacignore
and are not able to execute scripts per-se (such aspacignore
in the example above) because we exportLIB=1
inhelper*.sh
.Does it make sense to mask
pacignore
with a no-op for thetest/prompt_to_ignore
unit tests, since we already have dedicated unit tests forpacignore
intest/pacignore
? That way, we would only be testing howprompt_to_ignore
behaves with "y" or "n" answers and would keep everything related topacignore
separate.