Guard against missing setuptools

[NeilGirdhar]

Without the dependency on setuptools, poetry won't update setuptools when updating astroid. And if a user uninstalls setuptools, poetry won't reinstall it when updating. This causes the cryptic error "'pkg_resources' has no attribute '_namespace_packages' " when running pylint.

[Pierre-Sassoulas]

Are you on the latest astroid ? We used scm_setuptools in very recent version but we removed it in #1030 If we still need setuptools after 1030, I'd rather do what's necessary to not depend on it.

[NeilGirdhar]

@Pierre-Sassoulas I am on the latest. The trouble is this line in astroid/interpreter/_import/util.py:

return pkg_resources is not None and modname in pkg_resources._namespace_packages

I believe you can't access that without setuptools.

[Pierre-Sassoulas]

The code should not fail though, it's guarded by a try catch:

try:
    import pkg_resources
except ImportError:
    pkg_resources = None


def is_namespace(modname):
    return pkg_resources is not None and modname in pkg_resources._namespace_packages

I don't know how it's possible that you had an error. Did you do something particular to get the error ? It also look like distutils is used in a lot of place, (too much to refactor easily), maybe that's what should be added (it's included in setuptools, I guess)

[NeilGirdhar]

But that line doesn't guard against the missing setuptools?

Right now, I can't reproduce the error I got though. What I remember is that pylint was failing with that cryptic error, and then I installed setuptools and the error went away. I wish I could reproduce it.

[Pierre-Sassoulas]

It's possible that it's worse than just a dependency to setuptools and that we're depending on a specific version of setuptools (pkg_resources._namespace_packages is private, so...). If we have the wrong version (the out-dated default version of the system ?) pkg_resources is not None and we get the error. To be frank I don't know what is the purpose of this code, I'd like to remove it if possible but this seems like a big retro-engineering and refactor (because of the distutils dependency).

[NeilGirdhar]

It's possible that it's worse than just a dependency to setuptools and that we're depending on a specific version of setuptools (pkg_resources._namespace_packages is private, so...).

I actually tested this, and found that pylint fails with setuptools version 10, but it's mainly because setuptools 10 doesn't seem to work at all. Not sure if that's actually a problem.

To be frank I don't know what is the purpose of this code, I'd like to remove it if possible but this seems like a big retro-engineering and refactor (because of the distutils dependency).

Yes, that would be awesome if it's possible.

[NeilGirdhar]

Maybe you could just add another guard?

return pkg_resources is not None and and hasattr(pkg_resources, '_namespace_packages') and modname in pkg_resources._namespace_packages

[Pierre-Sassoulas]

Yeah you're right, let's do the fast fix and open another issue for the refactor. Do you want to add this to your MR ?

[NeilGirdhar]

Okay I'll do that

[NeilGirdhar]

Done

[Pierre-Sassoulas]

Thank for the fix. I think we might still need to add setuptools to the requirements (because of distutils used elsewhere) and you should add yourself to the contributor. Maybe you could rebase this on your original changes if you still have the commit name ?

[NeilGirdhar]

I overwrote it. It's just one extra line in your requirements, right? And I'll happily add my name to contributors.

[NeilGirdhar]

Done, except I couldn't find the contributors list ?

[Pierre-Sassoulas]

Ho nevermind for the contributors I'm confusing astroid with pylint where there is a Contributors.txt. git is tracking all this anyway :)