[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How does team maintenace of python module works?



On 02/20/2013 10:23 PM, Barry Warsaw wrote:
> On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote:
>
>> If sticking to our old habits is not the only valid point, that there
>> are real technical reasons why we should never be using a git tag
>> as the key for an upstream release, or if you think they might be
>> real difference between the "git archive" generated xz file and the
>> github/gitorious/etc. tag based tar.gz, please explain.
> You better be darn sure that upstream has excellent QA then, and that you know
> for sure that a tag is correctly assigned to a buildable, tested, QA passed
> snapshot of the project.

In what way the QA is different because it's a tag instead of a tarball ?
I don't understand your reasoning. In both cases, you must make sure
that what you are packaging is buildable, tested, QA, etc.

> Also, you must ensure that everything necessary to
> build and deploy the package is either included in the repository or is easily
> generated by something that is in the repository. I bet that's going to cover
> a minority of projects still. At least with a tarball, you know you have a
> releasable "thing" that upstream has blessed (which could still have problems,
> sure, but that's different than not being sure.)
>
> Look at it from a Debian Python packager's point of view.  If it's on PyPI,
> then there's no guessing.  If it's a git tag in some repo, you have to carry
> along much more implicit context (e.g. the workflow of the upstream project,
> do I have the right repo, etc.).

With many PiPY projects, I can see that the generated tarball are the
exact same thing as what's tagged in the Git repository. Often, the
release process is automated so the tag and the tarball are released
at once. This has been the case, for example, for:

- python-pecan (https://github.com/dreamhost/pecan)
- python-json-patch (https://github.com/stefankoegl/python-json-patch)
- python-json-pointer (https://github.com/stefankoegl/python-json-pointer)
- python-tablib (https://github.com/kennethreitz/tablib)
- cliff-tablib (https://github.com/dreamhost/cliff-tablib)
- python-warlock (https://github.com/bcwaldon/warlock)

(non exhaustive list... and not including all of Openstack!)

I don't understand your reasoning, they are all using setuptools, and
are perfectly buildable, installable, etc. Did I miss something?

Thomas


Reply to: