[Discussion] Load downloader by default

[Flame442]

What's the problem?

V3 has a philosophy of not loading any cogs by default, and only enabling the absolute bare minimum functionality in the bot's core on bot startup. This is to prevent users who have just installed Red from feeling overwhelmed by multiple pages of commands, many of which they may not want to use. An obvious example for this kind of thinking can be found looking at the Audio cog, and its 27 top level commands.

The black sheep of this philosophy has always been the Downloader cog, as is only has 4 top level commands which are intended to add the modularity that Red boasts as a major selling point. Currently, there is little reason to not have this cog loaded at all times, since almost all Red users will install at least 1 third party cog, and will want to be able to update that cog later.

How do we fix it?

There are a few different ways to approach making such a change:

Option 1 is to load Downloader by default in new installs, but is otherwise a normal cog after that. This will require the least amount of work to implement, and will not be nearly as much of a breaking change. Users can still decide to unload the Downloader cog if they for some reason wish to do so. However, this option will break the philosophy of V3, and may be slightly confusing for users who may not understand why this cog is loaded and no other.

Option 2 is to build Downloader into Core, similar to how CogManagerUI currently is. This will require more work, will be more of a breaking change, and will make it impossible for users to decide to unload the Downloader cog for whatever reason. However, it always being an available part of the bot will allow other cogs to more safely access its internals without having to also disable themselves when downloader is not loaded. It will also make it easier to make and support actual public APIs, rather than third party cogs like Neuro's updatechecker having to rely on internals. EDIT: It may make sense to consider #5943 at the same time this is done, while Downloader is receiving a major overhaul, if this option is picked.

Option 3 is to do nothing. Obviously this is the easiest option, but it means nothing will change.

What can I do?

We are looking for community feedback regarding this change. If you have any opinions or concerns regarding any of these options, or any options we may not have considered, please let us know in this issue. If we see enough support for this change, we may look in to making one of these changes for 3.6.0 (or some other breaking version thereafter).

[Drapersniper]

Not sure if the plan is still to merge @Twentysix26 Index cog with Downloader -

while the first would be the easiest is there any real work scenario where it makes sense to unload downloader?

the only thing I can think of is keeping the top level command namespace clear but not aware of any other commands that conflict with downloader anyways.

From a user perspective given how red is advertised it would make sense longterm to bundle it into core similar to CogManagerUI unless there is a clear benefit/reason to ever unload it removing the ability to unload would just simplify the majority of users experience - i.e no need to load Downloader when they inevitably want to install a new cog/update it etc

A quick and cheap way would be to go with option 1 first (potentially even as part of 3.5) and then merge into core as the next minor after

[Jackenmen]

Not sure if the plan is to merge @ Twentysix26 Index cog with Downloader

That would be a separate issue entirely.

[Twentysix26]

+1 on option 2 if there is real community interest in a Downloader public API. Otherwise, I don't see much reason to spend time changing a setup that works fine as is.

[wohali]

I like Option 2, but could see the value in having a global disable of downloading functionality (possibly out-of-band, an env var or startup option). I can't see the downside of always including the downloading functionality as long as it can be hard-disabled somehow.

As-is is great too, every use case is catered for, even if it is a special case philosophically.

[ltzmax]

I'll say +1 for option 2.
It sounds pretty alright option since I nearly never see anyone actually unload downloader, You pretty much need it for cog installing, repo adding and cog update / repo update.

[qenu]

+1 for option 2
Imo, cogs are one of the core features for Red.
Moving Downloader to Core sounds like the intuitive option.

[Kuro-Rui]

Imma say +1 for option 2
Since many people want to download another external cog, building Downloader into Core will reduce some work and this will be much more efficient.

[palmtree5]

+1 on option 2 from me

Reading this, it's the option that makes the most sense, since we do advertise being fully modular and a lot of that modularity comes from installing third-party cogs through Downloader