Add the supported targets page

[Miauwkeru]

• Add supported targets page with an extension
• Add the defaults for every type
• Remove unnecessary spaces from files
• Let autoapi also discover all _os.py modules

closes #84

[Miauwkeru]

When testing against autoapi, I did notice that a few projects fail when generating the api documentation. These are:

• dissect.cstruct
• flow.record
• dissect.target (because of the added support for _os modules in Let autoapi discover all _os.py modules #89 )
• dissect.qnfx
• dissect.shellitem

I'll make a ticket for those projects

[Miauwkeru]

How the table generation works. We have some default csv files that contain the descriptions.
for example _defaults/filesystems.csv contains the descriptions for all the different filesystems.

the _ext/supported_targets.py extension maps those descriptions together with all the filesystems it can find (within dissect.target.filesystems) and generates a csv file inside the supported_targets/ directory . (e.g. supported_targets/filesystems.csv ). If a description is missing for a specific filesystem it will generate a warning containing information on how to resolve it.

The output format depends on the type of file being generated (loaders looks different from filesystem for example), but it comes down to:

Class, ..., Description
:class:`link.to.filesystem.Filesystem`, ..., "Description for the filsystem"

the supported-targets.rst file uses a csv-table to read the generated csv file.

[Schamper]

Note that the original ticket did warn that an automated approach might be hard and not lead to a high enough quality result. If you do still intend to attempt to do it in an automated fashion, it must be better and lead to as high a quality result as a handcrafted table.

[Schamper]

Why is this so complex? What's wrong with just iterating i.e. loader.LOADERS?

Besides, it's giving a wrong impression on things that are supported. Not everything that's in dissect/target/filesystems is actually supported or should be listed here. Who cares about ITunesFilesystem if it can't actually be manually opened or selected? What value is there in knowing that it exists? I do care about the ITunes Backup loader (not ITunesLoader, what's that?).

This page should reflect what a user can expect from Dissect, not a factual representation of what modules and classes exist. I open the API documentation if I was looking for that.

[Schamper]

The CSV approach sucks a bit, is there not a better way? Maybe a custom table directive where you can manually override entries, keyed on the module name?

[Miauwkeru]

I thought a bit further about it, and having a plugin automatically generate it will be more effort than it is worth. So I opted to write it manually

[Schamper]

In general, remember that this page should not have too much implementation details. Someone reading this should not have to know what a plugin is. Any and all links or references to more in-depth or API stuff should be optional links, and not part of the main text.

Also, maybe vibe some sentences to make them flow nicer.

[Schamper]

Not a change in this PR, but why does this page like to dissect.target and not dissect? And "github" is not even properly capitalized...

Get in touch, join us on github <https://github.com/fox-it/dissect.target>_!

[Miauwkeru]

Good question

[Miauwkeru]

I adjusted it, just to be safe