Updating MANIFEST.in does not correctly update the package sdist creates #436
Comments
I have been hit by this same bug. My current remedy is to delete the |
The problema appears to be in the logic with which the
Files already in |
See also setuptools/setuptools/command/egg_info.py Lines 560 to 570 in d4c215a where the actual reading of SOURCES.txt takes place: rcfiles = list(walk_revctrl())
if rcfiles:
self.filelist.extend(rcfiles)
elif os.path.exists(self.manifest):
self.read_manifest() I cannot understand the reason for this logic. |
@jaraco I think I nailed down this old (annoying bug), but nobody cares of these old bugs. Should I reopen or provide a pull request? |
@miccoli: If this ticket describes the issue, it's still open. A PR would be most appreciated. |
@jaraco yes: this ticket is accurate. Since there is no discussion active, I assume that I should provide my own PR. |
addresses #436: Updating MANIFEST.in does not correctly update the package sdist creates
I think this change may have broken sdist installs with package data: #1016 |
The reason for rcfiles = list(walk_revctrl())
if rcfiles:
self.filelist.extend(rcfiles)
elif os.path.exists(self.manifest):
self.read_manifest() is now clear: in the develop tree (under SCM control) the files to be installed are determined from the SCM system ( This logic is broken for packages that do not use Unfortunately my PR #1014 badly brokes this intended behaviour, so that |
…pdate the package sdist creates"
Is there a fix to this now? Even if I delete |
@Firenze11 unfortunately my previous attempt at solving this bug (PR #1014) was catastrophic. (I'm still a little ashamed of the mess I made.) But from my analysis the only place where previous content of Can you please provide an example in which |
I really think SOURCES.txt should be cleared automatically at some point. This is very surprising behavior. I've been trying to figure out why the changes I was making to MANIFEST.in didn't seem to be working. |
setuptools has a long-standing bug that if files are removed from the list of sources but were included in a previous run of egg_info, they remain in the generated list of sources (pypa/setuptools#436). This affects egg_info and sdist. Let's work around this by removing the old SOURCES.txt if we can recreate it from git.
setuptools has a long-standing bug that if files are removed from the list of sources but were included in a previous run of egg_info, they remain in the generated list of sources (pypa/setuptools#436). This affects egg_info and sdist. Let's work around this by removing the old SOURCES.txt if we can recreate it from git.
setuptools has a long-standing bug that if files are removed from the list of sources but were included in a previous run of egg_info, they remain in the generated list of sources (pypa/setuptools#436). This affects egg_info and sdist. Let's work around this by removing the old SOURCES.txt if we can recreate it from git.
Hi I am running into the same issue, but I haven't quite figured out @miccoli @rsyring could you help me with a bit more explanations? I don't have a MANIFEST.in file and I am not quite sure what steps I should follow to have Thanks a lot for the help! |
@lucacerone This issue is specific to a setup with The only thing that you should be aware, regarding this specific bug, is that after each change to |
Thanks a lot @miccoli, I managed to get the "data" in my package by adding a I don't quite understand what happens to "data" that resides outside of the "package" folder (I know it's not the preferred way, and in the end I moved the folder within the package), because if I add it to the Manifest.in, in the resulting archive I see those folders, but then they don't get copied to the I think the documentation could be a bit more clear on what's going on under the hood, but in the end I found a way that works for me :) Many thanks for your answer, I really appreciated it! |
Originally reported by: spookylukey (Bitbucket: spookylukey, GitHub: spookylukey)
The behaviour of sdist depends on previous contents of MANIFEST.in, not just the current. This is not fixed even by running
setup.py clean
orsetup.py clean --all
(although this should not be necessary).This is very surprising behaviour, and potentially dangerous too - if someone accidentally adds a MANIFEST.in rule that includes a file that must not be distributed and notice the problem, they would expect that removing the rule will remove the file, but it does not.
I've attached a bash script that demonstrates the problem.
The text was updated successfully, but these errors were encountered: