You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've run into an interesting situation. gmusicapi, which is a library, is used by applications such as mopidy-gmusic. For gmusicapi to have 2/3 compatibility, we use python-future and install_aliases.
Now, it looks like install_aliases has the potential to cause problems for code that doesn't expect it. In our case, due to mopidy-gmusic's non-future compatibility layer, they're getting new types in places they don't expect (details/recreate steps in simon-weber/gmusicapi#493 (comment)).
So, my question: should libraries avoid the use of install_aliases for this reason? Or is that considered safe, meaning we should look elsewhere (eg at the behavior of future's intern(bytes()))?
The text was updated successfully, but these errors were encountered:
We've run into an interesting situation. gmusicapi, which is a library, is used by applications such as mopidy-gmusic. For gmusicapi to have 2/3 compatibility, we use python-future and install_aliases.
Now, it looks like install_aliases has the potential to cause problems for code that doesn't expect it. In our case, due to mopidy-gmusic's non-future compatibility layer, they're getting new types in places they don't expect (details/recreate steps in simon-weber/gmusicapi#493 (comment)).
So, my question: should libraries avoid the use of install_aliases for this reason? Or is that considered safe, meaning we should look elsewhere (eg at the behavior of future's intern(bytes()))?
The text was updated successfully, but these errors were encountered: