Tarballs at pypi aren't identical to git snapshot... which is suboptimal about sparqlwrapper

[wikier]

Tarballs at github are generated with git tags, while I always used the following command line to release to pypi:

python setup.py register sdist --formats=gztar,zip bdist_egg upload

But I'm open to recommendations how to optimize such details.

[wikier]

@olberger ping?

[gromgull]

Sparqlwrapper contains no binary components, you can get more portability by using sdist instead of bdist? (I think - or maybe it makes no difference since there are no binary components?)

[wikier]

@gromgull we are already using sdist, isn't it? Is there something like sdist_egg?

I'm not so expert on this part of the process, so all the help will be very valued :-)

[gromgull]

Sorry - I am crazy - I am sure the line you pasted said bdist when I wrote that comment.

RDFLib core I build only with sdist and no eggs - but it wont hurt either.

[wikier]

Never mind, @gromgull.

The problem pointed by @olberger is that both tarballs are different:

$ wget https://pypi.python.org/packages/source/S/SPARQLWrapper/SPARQLWrapper-1.6.0.tar.gz
$ wget https://github.com/RDFLib/sparqlwrapper/archive/1.6.0.tar.gz
$ md5sum *.tar.gz
d8e008fd1f2572c69912c7ec23c08308  1.6.0.tar.gz
5d9e0ce0949e17eab949ae82f3fcad4d  SPARQLWrapper-1.6.0.tar.gz

Because both contain different layout and content:

1.6.0.tar.gz:

sparqlwrapper-1.6.0/test
sparqlwrapper-1.6.0/test/wrapper_test.py
sparqlwrapper-1.6.0/test/dbpedia.py
sparqlwrapper-1.6.0/.gitignore
sparqlwrapper-1.6.0/README.md
sparqlwrapper-1.6.0/SPARQLWrapper
sparqlwrapper-1.6.0/SPARQLWrapper/SPARQLExceptions.py
sparqlwrapper-1.6.0/SPARQLWrapper/Wrapper.py
sparqlwrapper-1.6.0/SPARQLWrapper/__init__.py
sparqlwrapper-1.6.0/SPARQLWrapper/KeyCaseInsensitiveDict.py
sparqlwrapper-1.6.0/SPARQLWrapper/SmartWrapper.py
sparqlwrapper-1.6.0/SPARQLWrapper/SPARQLUtils.py
sparqlwrapper-1.6.0/SPARQLWrapper/jsonlayer.py
sparqlwrapper-1.6.0/LICENSE.txt
sparqlwrapper-1.6.0/setup.py
sparqlwrapper-1.6.0/MANIFEST.in
sparqlwrapper-1.6.0/ez_setup.py
sparqlwrapper-1.6.0/scripts
sparqlwrapper-1.6.0/scripts/example-optional.py
sparqlwrapper-1.6.0/scripts/example.py
sparqlwrapper-1.6.0/scripts/example-dbpedia.py
sparqlwrapper-1.6.0/scripts/sparql.py
sparqlwrapper-1.6.0/AUTHORS.txt
sparqlwrapper-1.6.0/ChangeLog.txt
sparqlwrapper-1.6.0/Makefile

SPARQLWrapper-1.6.0.tar.gz:

SPARQLWrapper-1.6.0/SPARQLWrapper
SPARQLWrapper-1.6.0/SPARQLWrapper/SPARQLExceptions.py
SPARQLWrapper-1.6.0/SPARQLWrapper/Wrapper.py
SPARQLWrapper-1.6.0/SPARQLWrapper/__init__.py
SPARQLWrapper-1.6.0/SPARQLWrapper/KeyCaseInsensitiveDict.py
SPARQLWrapper-1.6.0/SPARQLWrapper/SmartWrapper.py
SPARQLWrapper-1.6.0/SPARQLWrapper/SPARQLUtils.py
SPARQLWrapper-1.6.0/SPARQLWrapper/jsonlayer.py
SPARQLWrapper-1.6.0/LICENSE.txt
SPARQLWrapper-1.6.0/setup.py
SPARQLWrapper-1.6.0/PKG-INFO
SPARQLWrapper-1.6.0/MANIFEST.in
SPARQLWrapper-1.6.0/setup.cfg
SPARQLWrapper-1.6.0/SPARQLWrapper.egg-info
SPARQLWrapper-1.6.0/SPARQLWrapper.egg-info/PKG-INFO
SPARQLWrapper-1.6.0/SPARQLWrapper.egg-info/dependency_links.txt
SPARQLWrapper-1.6.0/SPARQLWrapper.egg-info/top_level.txt
SPARQLWrapper-1.6.0/SPARQLWrapper.egg-info/SOURCES.txt
SPARQLWrapper-1.6.0/SPARQLWrapper.egg-info/requires.txt
SPARQLWrapper-1.6.0/AUTHORS.txt
SPARQLWrapper-1.6.0/ChangeLog.txt

The difference is that tarball uploaded pypi only contains the module, and its binaries (eggs), not the other directories like scripts or test. I'm not sure how to handle this in the debian package, because even if we push to pypi those directories too, the release from github is a tag in the scm which will never contain the binaries. Any idea from the debian python team, @olberger?

[dayures]

@olberger currently, the tarballs are still not identical (but some steps have been done in order to align them).

BTW, @wikier what do you think to rename the folder scripts to examples? After having a look on the debian package, I think that it makes sense. https://packages.debian.org/stretch/all/python-sparqlwrapper/filelist

[dayures]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again!