Closed GoogleCodeExporter closed 8 years ago
Hi Sandro,
Including CHANGELOG is no problem at all. I will do that soon.
Regarding the tests: I am happy to ship these but I wondered if you had any
advice on how best to go about it? If I just add it to the py_modules list in
setup.py, then people who have installed it will be able to do "import
prettytable_test", right? For some reason it feels weird to me to have the
unit tests be so easily accessible. But maybe this is normal? I have read
this article:
http://as.ynchrono.us/2007/12/filesystem-structure-of-python-project_21.html,
which recommends having a test sub-package of your main package. But right now
PrettyTable is just a module, not a package, and I am loathe to change that
since it will break existing import statements, and also because I feel it is
overkill for such a simple library.
Since you package many Python projects for Debian I thought you may have some
insight?
Original comment by luke@maurits.id.au
on 6 May 2012 at 9:56
Hi Luke,
sadly the Python ecosystem is very fragmented when we talk about how to run
tests. Some have a test/ directory, so just have a module in their package so
running
python -c "import module; module.test()"
would work, and so on.
given setuptools supports it, it would be cool if you can fill the missing bits
for letting
python setup.py test
works. This patch just makes the trick:
Index: setup.py
===================================================================
--- setup.py (revision 56)
+++ setup.py (working copy)
@@ -17,5 +17,6 @@
author='Luke Maurits',
author_email='luke@maurits.id.au',
url='http://code.google.com/p/prettytable',
- py_modules=['prettytable']
+ py_modules=['prettytable'],
+ test_suite='prettytable_test'
)
as for installation, I don't think it is worth installing the tests, but being
able to run them when you have the tarball unpacked is nice.
Cheers,
Sandro
Original comment by sandro.tosi
on 12 May 2012 at 8:59
Hi Sandro,
I had no idea that setuptools had the test_suite option! Thanks very much. I
agree that packaging the tests and having the ability to run them with "python
setup.py test", but not actually installing the tests into site-packages
anywhere is a good way to go about things. I'll get this done soon and upload
the new packages to PyPi. I'll let you know when I've done so so you can make
Debian packages.
Thanks!
Luke
Original comment by luke@maurits.id.au
on 16 May 2012 at 12:48
Okay, I've uploaded the new packages. These should have CHANGELOG and
prettytable_test.py in them as requested. Please let me know if everything is
okay, then I can close this Issue.
Original comment by luke@maurits.id.au
on 16 May 2012 at 2:50
Mh sorry but where did you uploaded it? aaaah I see, you've overwritten your
previous 0.6 release. Please, don't do that! we won't notice that a new release
was /released/ if you don't bump the version too.
Do you think it's possible to restore the original 0.6 version and release a
completely new version, something like 0.6.1 ?
Original comment by sandro.tosi
on 17 May 2012 at 8:40
It would be possible to replace the old packages and then release these new
ones as 0.6.1, but I think I would need some convincing that this is actually
the right thing to do. I don't really think of the new packages as
constituting a new "release". I mean, the actual PrettyTable code itself has
not changed one byte. All that's different is that the tarball now includes a
few extra non-source files. To my mind this is a "new packaging", or
"repackaging" of an "old release". I sort of feel like calling it 0.6.1 would
confuse people, since 99% of users will not even notice a change.
Original comment by luke@maurits.id.au
on 18 May 2012 at 2:13
the problem is that once you publish something on the web, in particular for
software releases, it's "frozen" any further changes require a completely new
release.
For example, if you were to fix a typo in a comment (and you want to do that
because it's embarassing of some "urgent" matter), would you release a new
version or just "update" the current one?
How can anyone notice you've released a new version, while it's actually just
an "updated" version? I would not. I wouldn't have noticed you've release a
tarball with the doc in if I didn't really know that you did it and I searched
hard to understand where it is, given I was looking at the same version I
already downloaded some time before.
People are used to versions, because they mean something to them, they mean a
specific point in the software evolution that's unchangable, and from that on
you'll have higher versions releases.
I might not be the best speaker (writer? ;) ) but I hope at least you have
shown some opinion on why for any change, a new (different) release is needed.
Original comment by sandro.tosi
on 21 May 2012 at 8:15
Hi Sandro,
Okay, I will make a 0.6.1 release and restore the previous 0.6 packages, but
probably not for about a week since I am very busy with a conference deadline
at the moment.
Original comment by luke@maurits.id.au
on 27 May 2012 at 12:15
Hi Sandro,
This ended up working out quite nicely, since I got a bug report about unicode
in PrettyTable 0.6, so I would have ended up having to do a 0.6.1 release
anyway! I've released the new one today, and replaced the 0.6 packages on PyPi
with ones which do not contain CHANGELOG etc., as they originally were.
I'm going to close this issue now, since the originally problem is now fixed
(as CHANGELOG and prettytable_test.py are now in the 0.6.1 source distribution)
and the 0.6 packages have been restored to their original form.
Original comment by luke@maurits.id.au
on 3 Jun 2012 at 11:09
Thanks a lot Luke!
Original comment by sandro.tosi
on 6 Jun 2012 at 5:24
Original issue reported on code.google.com by
sandro.tosi
on 6 May 2012 at 7:59