Allow for varying import styles

[jshwi]

Works

from setuptools import setup


setup(
    ...
)

Does not work

import setuptools


setuptools.setup(
    ...
)

Results in:

No setup() call found in setup.py
can not perform sync

[jshwi]

@bryant-finney I might look at the options for this if you think it's worth perusing.

[bryant-finney]

@jshwi Ah interesting. Do you know if adding an import guard breaks it?

if __name__ == "__main__":
    setup (
        ...
    )

I'm also assuming being funky with the import would break it?

from setuptools import setup as silly
...
silly(
    ...
)

[jshwi]

@bryant-finney For the first one, I haven't checked. Can you fill me on a bit on how that may help? Curious to know. The second one I find interesting, hadn't considered that yet. I'll look into it.

[nelsyeung]

@bryant-finney The first one works. The second one fails.

[bryant-finney]

@nelsyeung and @jshwi

I can see that since the ast module is used, the import guard is correctly handled, which is great.

I'm wondering if the ast module provides a way to test equality between nodes.

Or in other words, if one were using a shell and inspecting the setup.py script:

>>> import setup      # an example; we can't actually do this

>>> import setuptools 

>>> def get_setup_func() -> Callable:
...    for obj in setup.__dict__.values():
...        if obj is setuptools.setup:
...            return obj
...    raise ValueError(f"could not find {setuptools.setup} function")

>>> the_func = get_setup_func()

>>> ...     # process the function call

I feel like the ast module might provide some way or another to implement the get_setup_func() above in order to handle cases where from setuptools import setup as something_else is used. But that's just a hunch.

[jshwi]

@bryant-finney I think you're right about the ast module, I haven't used it a great deal, this PR was a a bit of a WIP. I'm confident there's a cleaner way of doing this. I should be able to find the time to look into this.

[jshwi]

The answer to the second problem might be astroid, as per the pylint README

Pylint can infer actual values from your code using its internal code representation (astroid). If your code is import logging as argparse, Pylint will know that argparse.error(...) is in fact a logging call and not an argparse call.