New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Installation of packages fails after 28.7.0 upgrade: Documentation object is not iterable #833
Comments
For the record, can make installation pass if I hack this into py36compat.py at line 110: if not isinstance(item, tuple):
continue Obviously not the fix, but ya, setuptools doesn't seem to like the 'Documentation' object being passed in. |
Also downgrading to 28.6.2 makes this work.. |
same here, downgrading temporary solves the issue. |
@tweksteen, could you investigate. What is the cause? What's the proper fix? |
This issue also occurs when installing |
Working on another project noticed my builds were failing at rcssmin and then other packages. I tracked down the common error files and saw it was setuptools package, and found this issue. I too can vouch that there are issues with this version 28.7.0, and the work around is using 28.6.1 |
- Change document storage location back to default (Issue #34) - Update DEMO data (Issue #37) - Workaround for Issue #38 - setuptools v28.7 issue (pypa/setuptools#833) - Use specific version of Mayan EDMS for build (v2.1.4)
@jaraco I don't understand why you reversed this patch when the correct thing is to fix the failing package itself. I've reproduced the install of rjsmin. The backtrace is similar to this:
If you read a bit the code of that specific package, you will see that it is strongly hooking onto the setup process. If you traceback the setup call, you'll find that data_files is populated using a call to the find_data function. A bit further down, if you have a look at what is returned by that function, you will find that it builds a list of Documentation object (an internal class define in this package). Now, the standard Python documentation (3.7) mentions: At no point does it mention that it will accept random object... So yes, someone hacked onto the setup process and relied on the undocumented and inconsistent past behaviour of setuptools. Moving forward, the correct solution is to create a bug for that project. But this is not a setuptools issue. setuptools should follow the standard behaviour described in the Python documentation. |
I reversed the patch because a regression was reported and I don't have enough time to dig in and analyze the underlying cause. Thanks for doing that. I had the feeling that multiple projects were already filing complaints, but now that I review the history, I see that you have indicated that the issue is probably isolated to one or a few projects and they may be abusing the API. I'm happy to bring the change back if that's the right behavior. |
@tweksteen if there's a bug people rely on it's not a bug, it's a feature (as linus would say) and focus should be to not break userspace, see: https://lkml.org/lkml/2012/12/23/75 |
I wouldn't state it nearly as strongly as Linus did there. If this usage can be shown to be isolated to a single project (or just a few projects), and those projects can develop a solution avoid encountering the issue, then I'd have no problem re-introducing the behavior. |
The main thing I'd like to know - does the use of Documentation objects in |
I've added further technical details on that issue on the rcssmin bug tracker (ndparker/rcssmin#6). The extra setup code in that project is hooking onto the install_data command and translating the options later on. This is where the Documentation objects are 'flatten' to a list of pair of strings. That translation does not happen when running the egg_info subcommand. From a setuptools perspective, I'll create a new pull request with unit test to make sure that particular behaviour is tested. Additionally and since setuptools is a corner stone software of the Python community, we might want to setup larger integration tests where we install each of the top 100 Pypi packages (http://pypi-ranking.info/?) using the test version of setuptools. This will make sure this type of commit and rollback does not happen again. It will also give quantitative details on the impact of such change. |
I see that there is already this kind of test in test_integration.py. Would it be worth expanding these to cover Pypi top downloaded packages? |
If you make it the top 200 this would've been caught, as |
Perhaps. The integration tests as currently implemented are already brittle and somewhat broken (virtualenvwrapper and novaclient are marked xfail). I'm sure the situation would get messy if a dynamic list of hundreds of packages were tested. If someone is able to maintain those tests, I'd be all for it. We might want to add a command-line option to opt-in to those tests such that a developer running the tests locally wouldn't have to shoulder the burden of running those slow tests during development. |
FYI, I have run the integration test on the top 300 packages of Pypi and django_compressor has been the only package failing the installation with the patched setuptools. |
Getting a weird error:
TypeError: 'Documentation' object is not iterable
trying to install rjsmin in a brand new virtualenv with the latest setup tools. This is on Ubuntu 16.0.4 and my OS X machine does the same thing.The text was updated successfully, but these errors were encountered: