Suggestion: config/flag that restricts dorothy from installing further packages/dependencies.

[octavian-one]

Add system-wide configuration for automatic package installation behavior

Issue Type

Enhancement Request

Current Behavior

When running certain Dorothy commands (like get-filesystem), the system automatically attempts to install required packages without explicit user confirmation. In the observed case, the ripgrep utility installation process began automatically as part of the command execution.

Desired Behavior

Add a system-wide configuration option that allows users to control package installation behavior:

• Allow users to set whether package installations should be automatic or require confirmation
• Potentially support different levels of control:
  • Always ask
  • Never ask (automatic)
  • Ask only for new packages
  • Ask based on package size/impact

Use Case

Users may want to:

• Prevent unexpected package installations
• Review package requirements before installation
• Maintain stricter control over system modifications
• Understand dependencies being added to their system

Suggested Implementation

1. Add a new configuration option to support the different levels of control.
2. Modify existing commands to respect configuration
3. If set to "ask", present a clear prompt:

The command 'get-filesystem' requires the following packages:
- ripgrep from source: https://github.com/BurntSushi/ripgrep

Do you want to install these packages? [y/N]

Technical Notes

• Should maintain backward compatibility
• Could potentially be implemented per-package

Additional Context

This was observed while running get-filesystem, which triggered the setup_util_ripgrep installation process without user confirmation. While the automatic installation is convenient, it may not be desired in all environments or situations.

Let me know if you'd like me to clarify or expand on any part of this issue.

[octavian-one]

@molleweide what are your thoughts on this?

[balupton]

It is something possible, but I want to push back a little bit beforehand.

Ultimately, it does depend on your goal right? If your goal in this case is to get-filesystem, and ripgrep is needed for that, then would you give up on the goal by not installing ripgrep? It's akin to when we want to install package X via apt or homebrew etc, and it then says, to install package X we need to install these 20 other packages - how many people then select no to that prompt?

For implementation, we could have setup-util read a config var from setup.bash. The prompt should take into account whether the --optional flag was used in the setup-util invocation. The problem, and terrible UX will be when such a call is a few commands nested away, and not installing a package causes the callstack of several commands to fail - however, Dorothy is pretty good with error handling, so this shouldn't be an issue.

[molleweide]

At first glance i have to agree with Ben. If there is an easy way to signal to a command pipeline that it should not attempt to do something that could install packages going down the line. But I dont know how complex that would be to add.

It is either easy or complicated to add this. If it is just a simple variable then sure, but if it turns out to add lots of conditional complexity to pretty much all larger composed commands, then it feels like a lot of complexity for very little gain from a maintenance perspective.

But maybe it can be elegantly automated, however, I dont know if it is possible, and it is not urgent, but could however be a nice feature in the end..

[balupton]

An in-between alternative that's harmless could be listing dependencies inside the help text of commands, along with whether their installation is automated, and/or required/optional. Problem with this is it will have no visibility of nested deps, unless the help author manually goes hunting for such. Some tooling could probably be made to automate this to say 3 levels deep.

[molleweide]

that could prolly be automated by CI as well right?

[balupton]

that could prolly be automated by CI as well right?

Read my mind.

[molleweide]

it could also be a simple this command has deps or not to make it easy. I mean if a user takes issues with some dep X then it is there
own problem to investigate, but it would be easy to just make a global mode for dorothy that is restricted so that no deps are installed.

1. Flag commands if they will try to install deps yes or no.
2. User can specify certain packages that explicitly are not allowed to be installed maybe.

after these two then it beco{s just a whole ordeal in itself with different levels of granularity and then im like, just read the source instead..

[octavian-one]

@molleweide @balupton thanks for your input.

As a user, if I didn't know Ben I would have uninstalled Dorothy at that point and probably forgotten about it after that. The reason for this is that I am not used to anything acting as 'sudo apt-get' as a side effect. I may be mistaken, but I imagine those in an education environment, corporate environment, or any other place where there's system administration would feel the same.

After thinking on this more, as a user, I would also be fine if there was no per-package prompt and it was just an installation at Dorothy install time (ideally with a list of what will be installed). During updates, the screen could show the expected updates, removals, and installs.

You guys definitely know best as to what the priority of something like this should be. Thanks again!

[balupton]

There's def cross-over with #233

Is the issue the sudo usage? If ripgrep was installed to XDG bin home automatically without sudo, would that be an uninstall if Ben unknown? For solving #233 there will be a Dorothy install time config prompt for:

How would you like to handle commands that need sudo?

1. Prompt for the first invocation, then allow for the default duration
2. Prompt for every invocation
3. No sudo access at all, deny all invovations

While we could automate something to scan the deps of every command, to a certain nesting level, then show it in help text, and even say this dep is used by these commands; I'm thinking that then gets more complicated than a prompt configure; and would be too boring for me to code (PR/funding necessary). The immediate deps in immediate help tho would be easiest; then the config prompt at Dorothy install for whether all setup-util invocations require confirmation (there could also be a whitelist/blacklist of packages).

Tomorrow I'll write some proposals. Please continue contemplation.

[molleweide]

It is definitley possible to think more about this.

Dorothy is a dotfiels ecosystem as much as it is a shell/cli/bash dev lib.

And as a dotfiles system and lib that tries to solve problems it will subsequently also install necessary dependencies if required.

This might make some commands unusable if you cant/wont install any further deps.

From that perspective it might make sense to have some kind of flag that strictly forbids dorothy to install further programs.

This should be worked on over time.

1. add note to readme that informs user that dorothy is designed to try to install further deps.
2. if user disagrees, they will run dorothy in pure bash mode / restricted mode.
3. add more granularity over time.

[molleweide]

How would you like to handle commands that need sudo?

From a legal/corp perspective the solution could be to just state that dorothy will try to do these things..

and then just take it from there...

So instead of us first implementing some advanced analyzer, just add super explicit prompts that tell the user what to expect.

So that we manage expectations and make things more complicated later if necessary.

Cuz, if a newbie starts using dorothy, most things will be new to them and there is no way of handling all that. We can only tell them.
This is whats happening. Read up on this. otherwise....

[molleweide]

This is not a disagreement but just some additional philosphy: one goal of dorothy for me is also to setup a foundation for solving all possible problems you might have and so it is kinda inherent to the philosophy that dorothy would install necessary packages if required. So dorothy is like the interface and then you can do whatever inside of it and this means naturally that dorothy has and will install dependencies.

[octavian-one]

@balupton I can see the cross over to 233 (which I have read when it was discussed in the co-working session a while back).

If the implementation of identifying dependencies requires some form of analysis of the source to identify what may be installed, I'm happy to give the development of that a try.

I think there's a level of complexity in this 'package management' which may ultimately not fall within the scope of Dorothy, to @molleweide its ultimate goal is to accomplish what you need of it.

However, I want to share some other things I found in case it is of value:

There's an apt-file / auto-apt that may be of interested:

https://www.linuxquestions.org/questions/programming-9/bash-function-to-check-if-script-dependencies-are-installed-4175572568/#post5777118

Upon further research, I've discovered apt-cache search which looks promising: https://askubuntu.com/questions/160897/how-do-i-search-for-available-packages-from-the-command-line

However, if this dependency identification cannot be cleanly implemented then I propose that a 'proxy' for it is not developed but that the Github / program simply has a list of dependencies that is documented.