Daniel Woste

I totally got your points and my main motivation was to have a page, which gets updated on its own without any effort from my side. So it is "never"...

I like the idea, but I'm afraid that this change is a tough one, as `.` as seperator is somehow hard-coded at a lot of places. So the next step...

The idea is good. As a not-so-nice workaround, you could use ``needextend`` to set the tag later. Untested example: ```rst My Needs -------- .. list2need:: :types: req :tags: MyComponent *...

The first one is correct, so it's just a "flat" dictionary.

Here is a technical proposal for the problem. It shall fix the following problems: * With the use of multiple `needimports`, the same JSON file gets loaded each time *...

Correct, the data is not available as long as it got not imported via `needimport`.

The idea is good, but I'm not sure if sourceline is a good argument. In a lot of projects, the need objects are stored on different files, get imported by...

Assigning functions to `needs_functions` is not the best way, as it also deactivates incremental build. Have you taken a look at the related documentation? https://sphinx-needs.readthedocs.io/en/latest/configuration.html#needs-functions There is a note, that...

So for me, the Sphinx warning is correct. But maybe Sphinx-Needs itself should throw such a warning and give the hint to use the API instead.

For -c option, a plugin could register this function via CommandPattern. But this plugin must be loaded before any other user defined plugin, so some kind of "internal_plugins = []"...