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
Please make the generated requires.txt files reproducible #458
Comments
Original comment by jaraco (Bitbucket: jaraco, GitHub: jaraco): I agree with the sentiment here, but I'm unsure about the patch. I know order of resolution is important, so sorting lexicographically could violate other expectations (or goals). I'd prefer if setuptools could capture the user's order and retain that. I haven't had a chance to investigate this in more detail, so I don't know what implications that retention would have. Would you be willing to explore that possibility? |
Original comment by lambyuk (Bitbucket: lambyuk, GitHub: Unknown): Three points: First, I doubt it makes any difference whatsoever. Second, sorting lexographically and possibly introducing unexpected expectations would be at least no worse than the status quo which is—as the bug title implies—a non-determinstic output. Nobody can really be relying on the current behaviour as it's inherently unreliable! Lastly, nobody should be relying on the current behaviour without a reams of comments. Just far too bizarre and/or the software is broken in some other, horrible, way. |
@jaraco any updates on this? debian is already applying a custom patch to this issue. currently this is blocking reproducible python builds for our distro. I hope we can get some movement here after 2 years |
Apologies for the delay. It’s the unfortunate situation that passing time affords little benefit for open Setuptools tickets (with the exception of regressions). Pull Requests get the lion’s share of attention. But I’ll see if I can knock this one out. |
I'm trying to understand the issue. By using the patch as a starting point, I'm looking at how I'll see if I can replicate the finding as reported, but my suspicion is it happens only if the package being built uses a non-deterministically ordered sequence (set or dict) for their |
Although i pushed that commit with the 'fix' (application of the patch from the bitbucket ticket), I've stripped that commit and I'm pushing the tests separately. Using c461d51, I've determined that the issue exists only when the requirements were declared by the user in a non-deterministically-ordered sequence:
Therefore, the fix should be to either disallow such declarations or to only re-order the declaration when it's not provided in a deterministic sequence. |
According to the docs, |
… non-deterministic order, they may appear in the metadata in non-deterministic order. Ref #458.
Although I considered first releasing a deprecation for this behavior, since the documentation has always stated that |
setuptools > 38.0 don't support unordered sequences in the install_requires param The set sequence is passed as a list now See: pypa/setuptools#458
Since closing pypa/setuptools#458, setuptools no longer accepts unordered sets for a dependency lists, which makes any setup.py call fail with the following error, breaking the installation: error in pygogo setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers; Unordered types are not allowed Since we don't care about the order at this point, let's just force it to be a list. Signed-off-by: Peter Gyongyosi <peter.gyongyosi@balabit.com>
Since closing pypa/setuptools#458, setuptools no longer accepts unordered sets for a dependency lists, which makes any setup.py call fail with the following error, breaking the installation: error in pygogo setup command: 'install_requires' must be a string or list of strings containing valid project/version requirement specifiers; Unordered types are not allowed Since we don't care about the order at this point, let's just force it to be a list. Signed-off-by: Peter Gyongyosi <peter.gyongyosi@balabit.com>
Originally reported by: lambyuk (Bitbucket: lambyuk, GitHub: Unknown)
Filed in Debian as https://bugs.debian.org/804249
The text was updated successfully, but these errors were encountered: