Skip to content

Remove dependency on distutils - #161

Closed
chriskuehl wants to merge 1 commit into
bugsnag:masterfrom
chriskuehl:remove-distutils
Closed

Remove dependency on distutils#161
chriskuehl wants to merge 1 commit into
bugsnag:masterfrom
chriskuehl:remove-distutils

Conversation

@chriskuehl

Copy link
Copy Markdown
Contributor

distutils is vaguely "legacy" and on some systems (e.g. Ubuntu 18.04) it's no longer included with the default Python installation, and requires an additional system package (python3-distutils) to be available, making it slightly harder to use bugsnag.

We can get the same kinds of information from sysconfig instead, which is a part of the stdlib and generally provides the same behavior, e.g.:

>>> distutils.sysconfig.get_python_lib()
'/home/ckuehl/proj/buggo/venv/lib/python3.6/site-packages'
>>> sysconfig.get_path('purelib')
'/home/ckuehl/proj/buggo/venv/lib/python3.6/site-packages'

In the long term, I think it probably makes the most sense to actually report all of sys.path along with errors, rather than just this one value. I can submit a patch to do this if you'd be interested.

distutils is vaguely "legacy" and on some systems (e.g. Ubuntu 18.04)
requires an additional system package (python3-distutils) to be
available, making it slightly harder to use bugsnag.

We can get the same kinds of information from sysconfig instead, which
is "more" a part of the stdlib and generally provides the same behavior,
e.g.:

    >>> distutils.sysconfig.get_python_lib()
    '/home/ckuehl/proj/buggo/venv/lib/python3.6/site-packages'
    >>> sysconfig.get_paths()['purelib']
    '/home/ckuehl/proj/buggo/venv/lib/python3.6/site-packages'

In the long term, I think it probably makes the most sense to actually
report all of `sys.path` along with errors, rather than just this one
value.
@GrahamCampbell

Copy link
Copy Markdown
Contributor

The module you're using instead doesn't seem to exist on Python 2.6, so tests are failing?

@asottile

Copy link
Copy Markdown

Is python2.6 still being supported? It has been end-of-lifed for just under five years (october of 2013 was the last security-only release).

@chriskuehl

Copy link
Copy Markdown
Contributor Author

+1 for dropping python2.6 in 2018, though I can understand if you still feel it's valuable to support.

If we went the sys.path route (which I think is probably better anyway) we wouldn't need to worry about sysconfig, but it would change the fields that are reported which may be problematic.

Note that the tests are also failing on python3.3 because that's also pretty ancient (and now no longer supported by pkg_resources).

@GrahamCampbell

Copy link
Copy Markdown
Contributor

There are various reasons why people can't upgrade, and it makes sense for Bugsnag to be available to as many people as possible.

@GrahamCampbell

Copy link
Copy Markdown
Contributor

Not my call though. :)

@kylef

kylef commented Aug 16, 2018

Copy link
Copy Markdown
Contributor

Wouldn't be too hard to support both, for example:

try:
    import sysconfig
    def get_python_lib(): sysconfig.get_path('purelib')
except ImportError:
    # Compatibility with Python 2.6
    from distutils.sysconfig import get_python_lib

get_python_lib()

Then it will work on Python 2.6, 3.3 etc

@asottile

Copy link
Copy Markdown

3.1 and 3.2 came after 2.6 but aren't supported - - why hold onto 2.6?

@kattrali

Copy link
Copy Markdown
Contributor

3.1 and 3.2 came after 2.6 but aren't supported - - why hold onto 2.6?

Nobody is using 3.1, and 3.2, while there are some holdouts on 2.6 (for Bugsnag, anyhow). It will likely go with the next major revision, which will probably be soon. In the meantime, I've tested and merged a backwards-compatible version (thanks @kylef!) and gotten the CI suite back in shipping order. A release will go out in short order.

In the long term, I think it probably makes the most sense to actually report all of sys.path along with errors, rather than just this one value. I can submit a patch to do this if you'd be interested.

That sounds like a good idea! Perhaps in a new metadata option libRoots? We can discuss in a new issue.

Thanks again!

@kattrali kattrali closed this in e419183 Aug 16, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants