.DS_Store file included in whl when building on Mac

[waylan]

.DS_Store files are created by the system for every directory on MacOS. However, I would not expect them to exist within a wheel. Yet, after building a wheel of my package (which we'll call foobar), I end up with the following file structure within the root of the wheel:

- foobar/
- Foobar-3.1.dist-info/
- .DS_Store

Note that .DS_Store files do not exist in any of the sub-directories, only in the root directory. The only other mention of .DS_Store in the wheel is an entry in Foobar-3.1.dist-info/RECORD which lists the file along with all other files included in the wheel:

.DS_Store,sha256=OfLZLRvDHtaZ3tF9i25UoJtjltEuP1xdggL5XdUtokg,6148

I wondered if I had perhaps inadvertently added the file by inspecting the wheel after creating it. However, the file being listed in RECORD suggests is was added by the build tool. Of course, as .DS_Store files are hidden on MacOS, I didn't notice the file when inspecting the wheel. It was only after a user reported an issue that it came to my attention. According to the user, "This triggers an error during installation because we are blocking this file name on our storage system."

Wouldn't it make sense for the wheel builder to exclude .DS_Store files?

Or, is there a way I can tell the wheel builder to exclude them?

[waylan]

I just checked and the Foobar-3.1.tar.gz source distribution I built at the same time does not contain any .DS_Store files (and none are listed in the SOURCES.txt file). The inclusion of the .DS_Store file seems to be unique to the wheel. The build was run using the following command:

python setup.py bdist_wheel sdist --formats gztar

[agronholm]

I don't have access to a Mac, but if you do mkdir foo does that also create the foo/.DS_Store file?

[agronholm]

I couldn't find anything in setuptools either that actively deals with .DS_Store files.

[gtback]

I believe that .DS_Store files are only created when you open the directory in Finder. @waylan I've always used the MANIFEST file to make sure they don't get included. It's possible wheel could do something specific to exclude them, but I would personally try other methods first.

[agronholm]

@waylan if you do rm -rf build and try again, do you still get a .DS_Store file in the wheel?

[agronholm]

@gtback Yeah, that was my understanding as well. The user must have entered the build directory in Finder in order for this to have happened.

[waylan]

So I have a makefile which defines a deploy command with the following:

.PHONY : deploy
deploy:
	rm -rf dist
	python setup.py bdist_wheel sdist --formats gztar
	twine upload dist/*

I suppose its possible I did things manually, but I can't imagine why. I'll try some test builds when I get home and report back.

[waylan]

It seems that the build dir was the problem. No matter what I did, every build included a .DS_Store file until I deleted the build dir. Once I did that, I no longer get any .DS_Store files. To avoid future problems, I have added rm -rf build to my makefile.

My assumption here is that when doing a new build, the build dir is not deleted and then recreated, but rather the contents are overwritten, which is what was causing the problem. Presumably at some point I had used the finder to look at something in the build dir, which added the .DS_Store file. Frustratingly, even with hidden files set to be visible, the .DS_Store file is not shown. It doesn't even get listed with ls -a. What I find curious is that this is not a problem for sdist. The tar.gz distributions don't get the DS_Store files even if they exist in the build dir.

[agronholm]

The problem lies with the distutils build command which does not clean up after itself.

[miccoli]

In fact this is a duplicate of #147

[parassjain]

find ~ -name ".DS_Store" -delete

this worked for me