Public dependency manager

[moltob]

In order to implement #288, this PR stores the dependency manager in a global registry class before task are loaded or executed.

This allows to get it from any code inside a task generator, e.g. from clean to read the previous execution result, see the contained sample.

The original discussion suggested to implement the registry as plain Python dict. I'd like to prevent string-based access and therefore implemented a very simply static class in new module doit.globals.

[coveralls]

Coverage decreased (-57.4%) to 41.667% when pulling 32b4307 on moltob:feature/public-dependency-manager into 2b59b89 on pydoit:master.

[moltob]

@schettino72 Where would I link a sample snippet into the docs, what would be a good spot?

[schettino72]

I will rebase this before reviewing it...

[schettino72]

Actually quite complicated to rebase this to master... I gave up.
I think it is easier no manually apply your changes. sorry for the trouble. I could do that myself later, not today.

Your Globals as Registry implementation is ok. I think the get_dep_manager turned out be useless. We can just ask user to import Globals and remove get_dep_manager. What do you think?

Regarding the documentation, your example i would like to put in a new HOW-TO section. dont worry about that now, we can do it later.

But Globals would need to be documented now, not sure where... here I would you use a simpler example (with just actions without clean).

[moltob]

Don't worry, I'll fix the branch and will incorporate your comments.

[moltob]

@schettino72 The diff is clean now, you can add your comments for the files, but I can easily just remove the access function as well. I'll do that tomorrow.

[moltob]

I just rebased the code cleanly onto master locally, will push it tonight.

Regarding the sample I'd like to keep the clean. IMHO this is one of the main use cases for that feature. A slightly simplified sample will be part of the pushed branch.

[moltob]

@schettino72 Please pick up review, rebase onto master is complete. Please see my above comments on having clean in the sample.

[schettino72]

Could you add the type here

[schettino72]

So it is still missing docs, right?
I guess this feature does not fit any of the existing pages... I would create a new page between task_args and uptodate.

Example is better now. There are so many use-cases for this feature...

I noticed sometimes users tend ignore a feature if the example is not trivial and do not reflect their use-case.
So I usually prefer minimal examples where the only feature being show is the one discussed. And leave to the user to figure out how put all doit features together to solve their problems :)

[moltob]

@schettino72 Docs added.

[schettino72]

the file is called 'globals' the the title is 'singletons'... we should use just one name...

you write the docs as if we would have many globals, not sure that would be the case. maybe we could expose the Reporter or some other internal stuff. But those are already documented elsewhere...

what about have this section of docs being specific to 'db backend' or something like that.

Another thing i just realized is that we are calling it 'dep_manager' as it is original function on doit itself.Wondering if we should use a more generic name. In practice users could use this to store some data. like a a task that stores and use a data itself in future runs. for this use-case the name dep_manager is completely innapropriate.

what do you think?

[moltob]

I'll adapt the section title to match file and module name.

you write the docs as if we would have many globals

Correct, this way, it will be easy to extend it when needed. I certainly would not add anything here just to have more than one attribute.

Regarding the names: I surely stumbled upon the names initially as well. There is a class Dependency that is called dep_manager wherever it is used and in fact it is actually the doit database...

But I got over it 😃 If you want to rename it and clean this up, I'd ask you to do this in a separate PR, if you don't mind. I maybe would have called things differently here and there, but that is really a personal thing...

[moltob]

Added docs about dep_manager API, some of the backend API and the different backends.

[schettino72]

Merged, thanks. Nice to have a regular contributor 👍

Notes:

• There is a spell checker task for docs doit spell (requires installation of hunspell).
• on docs I like breaking lines on period, etc. Makes it easier to review changes and not having very long lines (still max 80 column per line)
• your sample was broken. there is also a task to check them doit samples_check (not sure they work on Windows).
• after all I guess the name dep_manager is ok.
• I also exposed Globals as doit.Globals, doit.globals.Globals was looking like Java 😛