search

jdunck / python-unicodecsv

Python2's stdlib csv module is nice, but it doesn't support unicode. This module is a drop-in replacement which *does*. If you prefer python 3's semantics but need support in py2, you probably want https://github.com/ryanhiebert/backports.csv
Other
594 stars 88 forks source link

0.9.4 on pypi and github (tag) are different #19

Open toabctl opened 11 years ago

toabctl commented 11 years ago

Seems that the tar.gz files from pypi and from github tags for version 0.9.4 are different. sha256sum's are different and the release on pypi doesn't contain the testrun program so when I try to run the tests, I get:

./setup.py test running test running egg_info writing unicodecsv.egg-info/PKG-INFO writing top-level names to unicodecsv.egg-info/top_level.txt writing dependency_links to unicodecsv.egg-info/dependency_links.txt reading manifest file 'unicodecsv.egg-info/SOURCES.txt' reading manifest template 'MANIFEST.in' writing manifest file 'unicodecsv.egg-info/SOURCES.txt' running build_ext Traceback (most recent call last): File "./setup.py", line 26, in 'Programming Language :: Python :: Implementation :: CPython',], File "/usr/lib/python2.7/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/lib/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line 138, in run self.with_project_on_sys_path(self.run_tests) File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line 118, in with_project_on_sys_path func() File "/usr/lib/python2.7/dist-packages/setuptools/command/test.py", line 164, in run_tests testLoader = cks File "/usr/lib/python2.7/unittest/main.py", line 94, in init self.parseArgs(argv) File "/usr/lib/python2.7/unittest/main.py", line 149, in parseArgs self.createTests() File "/usr/lib/python2.7/unittest/main.py", line 158, in createTests self.module) File "/usr/lib/python2.7/unittest/loader.py", line 128, in loadTestsFromNames suites = [self.loadTestsFromName(name, module) for name in names] File "/usr/lib/python2.7/unittest/loader.py", line 91, in loadTestsFromName module = import('.'.join(parts_copy)) ImportError: No module named runtests

jdunck commented 9 years ago

I imagine people are no longer using this old version -- I'm closing this issue. Please reopen if it still affects you.

lfam commented 8 years ago

I have the same issue "ImportError: No module named runtests" using the 0.14.1 PyPi release, but not the GitHub tarball.

I'm building on Python-2.7.10, with setuptools-18.3.1 and unittest2-0.5.1.

Please let me know if I can provide more information about this issue.

ryanhiebert commented 8 years ago

The tar.gz on PyPI won't be the same as on GitHub. The tags on GitHub are tarballs of the entire repository, but the ones in PyPI are often only the parts needed to run the package. It's quite common for the tests to not be included in the PyPI distribution.

I can't speak for @jdunck, but I personally don't include tests in my Packages on PyPI, so I don't find the use case of running the tests in those tarballs to be one that I want to support.

lfam commented 8 years ago

My use case is packaging python-unicodecsv for GNU Guix [0].

We always prefer to run the tests of software we distribute. This practice helps ensure the safety of our users and it helps find bugs upstream.

We also prefer to take source code distributions from PyPi when appropriate. It's rare in my experience that PyPi distributions remove test suites. In this case, it sounds like you prefer packagers to use the GitHub tarballs. Is that correct? If so, that's fine.

[0] http://www.gnu.org/software/guix/

ryanhiebert commented 8 years ago

I have no opinion on that necessarily. I'm also not the author of this package, so my comments are merely my own. My thinking is simply that PyPI is for users of packages, who don't need the tests, so I don't include them. Is this not an issue that you have had with other Python packages?

lfam commented 8 years ago

I've only packaged about ~50 Python packages so far, but I've only had this issue with one other package. I've found that many minor Python programs are only distributed through PyPi, which means that distros have to use PyPi as the source of their packages. Also, PyPi provides a consistent interface across packages which makes it easy to do things automatically generate packages and package updates; GitHub doesn't.

I think that distros running tests is very important, btw.

Like I said, I'm happy to base our package on the GitHub distribution. I think I was confused by @jdunck's earlier comment. I didn't realize this was a WONTFIX.

ryanhiebert commented 8 years ago

The issue was considered outdated, not necesarily invalid. I'm going to open this up, so @jdunck can give comment when he has the time.