apply stubs to more than one module at a time about monkeytype HOT 14 OPEN

How about something like this?

❯ monkeytype list-modules | xargs -n1 monkeytype apply

from monkeytype.

+1 monkeytype apply somemod --recursive

from monkeytype.

I've been using this command to create a file for all possible stubs:

monkeytype list-modules | xargs -n1 -I{} sh -c 'monkeytype stub {} > stubs/{}.pyi'

from monkeytype.

The stubs would be used by the IDE or other tools.

from monkeytype.

Good idea!

from monkeytype.

@thedrow - How are you imagining that this would be used? For most projects the number of generated stubs will likely be too large to be consumable in a useful manner.

from monkeytype.

@mpage Not all projects are that big :-) I've worked on plenty of projects in the past with module counts in the tens, rather than hundreds or thousands, where it would be reasonable to just want to apply all types and fix all type errors in a single go (but there are still enough modules that it would be a pain to run monkeytype separately for each one.) A couple further thoughts:

1. I can easily envision how this would work for monkeytype apply, not so much for monkeytype stub, since we currently dump stubs directly to stdout. I think any multi-module output mode would need to create a directory tree on disk instead.
2. I think it might be better to think of it as a recursive mode (like monkeytype apply somemod --recursive, which would apply to all submodules as well) rather than --all. The latter just makes things really dependent on having the right code filter in place at tracing time, otherwise it gets totally out of hand.

I don't think I'm likely to work on this, but to me it seems interesting enough to warrant leaving the issue open.

from monkeytype.

Just a suggestion to use

monkeytype stub .

form

from monkeytype.

@msoedov Thanks for the suggestion! Can you clarify what semantics you'd envision for monkeytype apply .? Would it try to apply all stubs present in the trace store? Or all stubs for modules within the current working directory (recursively)? The dot suggests the latter to me.

It seems like one downside of this suggestion is that it's less flexible; unlike a -r flag, it doesn't generalize to picking any module and applying all stubs within it, recursively. IOW it doesn't have any equivalent for monkeytype apply some.module -r.

from monkeytype.

@carljm @msoedov

Is anyone working on --recursive / -r option? If not, I can take a crack at it. Any opinions on implementation?

from monkeytype.

@johnarnold I'm not aware of anyone working on it, take it away!

from monkeytype.

Any progress on this? Even just being able to pass multiple modules to be annotated in a single pass would be really useful (as it should avoid the overhead of needing to read in the database, which for larger projects can be substantial).

from monkeytype.

I'm not aware that anyone is working on this currently. If you'd like to work on it, pull requests are welcome! IMO either "allow passing multiple modules to apply" or "add --recursive option to apply" are reasonable design options. In either case stub would remain unchanged.

from monkeytype.

I use this powershell script on Windows:

$modules = monkeytype list-modules
New-Item -Path "stubs" -ItemType Directory -ErrorAction Ignore
foreach ($module in $modules) {
    $stub = monkeytype stub $module
    $stub | Out-File -FilePath "stubs/$module.pyi" -Force
}

from monkeytype.