Skip to content

[FR] Project Based plugin management #65

Description

@LeCheenaX

Obsidian is a powerful and flexible tool. And there are 2 main modes in using Obsidian:

  1. Project mode: Each project has a vault. And plugins are bound to the specific vault. So different vaults have different sets of plugins.
  2. Personal Knowledge/Projects Management(PKM) mode: All projects are in one personal vault. Often for study uses.

For Personal Knowledge/Projects Management(PKM) mode, there may be multiple projects in the same vault. As those projects were being worked in different time, the required plugins for viewing those projects may be different. For example:

  • Project regarding data collecting: I have visualizaiton plugins for viewing csv and exporting, and multiple visualization plugins.
  • Project regarding code: I have git plugins and AnyBlock plugins for visualization.
  • Other projects or miscellaneous: I have better plugin manager, sync plugin, etc.

I may access a project once a month, or once per half year, but I would have to let these plugins that may only be useful in certain projects enabled using lazy loading. Although BPM could reduce start time as those plugins are lazy loaded, it still bring performance burdens while leaving them background.

I tried the grouping feature, it is so useful that I could bulk enable/disable plugins related to certain projects, when I realized that I need to. But this is not the best solution when I switched from Project A to Project B: some plugins conflict with the other one, and I would have to manually bulk disable plugin group A, and manually enable plugin group B. It is annoying to remember doing this, and it interrupts thinking.

An idea solution would be binding plugins to certain projects(technically, bind to folders). For instance, Project A is placed in Archived/Folder A, and I could set to enable the plugin group for Project A only when a file is opened from Archived/Folder A.

  • this would not conflict with start-up plugins by only allowing plugins to be manually enabled to bind to the project.
  • this would not conflict with subProjects by disallowing or warning if the specified folder path is a subfolder.
  • this is an optional feature, so there should be no impact for upgrading.

This would make the plugin management more elegant.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions