Re: Current state of packaging Python software for Debian
Yaroslav Halchenko <debian@onerussian.com> writes:
> On Wed, 15 Jun 2011, Zygmunt Krynicki wrote:
> > Well joke aside you cannot fix the tarball that people release on
> > pypi with half of the test code and data missing just because their
> > MANIFEST.in was flaky.
>
> ;-) And that is when my evil "package from VCS" comes into play. For
> some projects I package directly from a clone of upstream GIT (or even
> gitsvn'ed upstream's SVN). And then I deal with actual sources, not
> with possibly stripped or crippled source distribution, so I can fix
> any issue like the one you brought up.
What I do, and would recommend other packagers to do, is to have that
situation prompt a discussion with upstream about fixing the broken
tarball release.
I see it as part of an OS packager's job to be an advocate on behalf of
other OS packagers and users, informing/educating upstream about release
practice improvements that can make their work more useable by the
community.
> Sure thing such approach is not universally-advisable: has its own
> cons as well.
Indeed. If an OS packager needs to start packaging from arbitrary VCS
revisions instead of upstream-released tarballs with official version
strings, I think that's a strong sign that the project's release process
is (socially) broken and needs to be fixed upstream.
> > If we are talking from a perspective of upstream developers that
> > also maintain their packages then I would *love* to see setup.py
> > sdist-test and would use it each day.
>
> ;-)
How would a putative ‘sdist_test’ differ from ‘test’? Why is this an
argument for a new command, and not an argument to improve what is done
by ‘test’ anyway?
--
\ “I do not believe in forgiveness as it is preached by the |
`\ church. We do not need the forgiveness of God, but of each |
_o__) other and of ourselves.” —Robert G. Ingersoll |
Ben Finney
Reply to: