Re: GnuPG signatures on PyPI: why so few?

2017-03-13 Thread Hans-Christoph Steiner
Donald Stufft: > >> On Mar 12, 2017, at 10:35 PM, Paul Wise wrote: >> >> On Mon, Mar 13, 2017 at 4:28 AM, Jeremy Stanley wrote: >> >>> upload them to PyPI since the authors of the coming Warehouse >>> replacement for the current CheeseShop PyPI have already indicated >>> that

Re: I want to maintain my current packages within the team

2017-03-13 Thread Thomas Güttler
What is the next step now? Regards, Thomas Güttler Am 10.03.2017 um 09:27 schrieb Thomas Güttler: Hi, I am following this instruction: http://python-modules.alioth.debian.org/policy.html Yes, I accept the above policy. Yes, collaborative maintenance is preferred. Here is what I want to

Re: PyPI source or github source?

2017-03-13 Thread Thomas Goirand
On 03/12/2017 11:34 AM, Ghislain Vaillant wrote: > On the other hand, I have seen very few pieces of software which had a > *comprehensive* MANIFEST.in for generating a tarball suitable for > packaging. The file is often either absent, or missing inclusion of the > docs, tests, change log or

Re: GnuPG signatures on PyPI: why so few?

2017-03-13 Thread Barry Warsaw
On Mar 12, 2017, at 11:46 AM, Ben Finney wrote: >What prospect is there in the Python community to get signed upstream >releases become the obvious norm? I don't know. Digital security seems to be mostly an afterthought unfortunately. I always use `twine upload --sign` so all my projects have

Re: PyPI source or github source?

2017-03-13 Thread Jeremy Stanley
On 2017-03-13 17:55:32 +0100 (+0100), Thomas Goirand wrote: [...] > IMO, upstream are right that the PyPi releases should be minimal. They > are, from my view point, a binary release, not a source release. > > It makes a lot of sense to therefore use the git repository, which is > what I've been

Re: PyPI source or github source?

2017-03-13 Thread Barry Warsaw
On Mar 12, 2017, at 01:19 PM, Brian May wrote: >Should we be using PyPI as our source of packages? Or github? PyPI for two reasons: not every developer uses git, and even those that do may not use GitHub. I've so far only encountered one package that releases on GitHub and not PyPI: pyparted.

Re: PyPI source or github source?

2017-03-13 Thread Barry Warsaw
On Mar 13, 2017, at 05:55 PM, Thomas Goirand wrote: >IMO, upstream are right that the PyPi releases should be minimal. They >are, from my view point, a binary release, not a source release. Wheels should be considered a binary release, but tarballs should still be considered the canonical source

Re: Updating Celery, Kombu, python-amqp

2017-03-13 Thread Brian May
On 2017-03-14 14:48, Christopher Hoskin wrote: > For reasons of my own, I need to create a Celery 4.0.2 Debian package. This > means also updating the Kombu and AMQP packages. As I'm doing this work > anyway, > my preference would be to share it with the World through DPMT. > > However, I

Updating Celery, Kombu, python-amqp

2017-03-13 Thread Christopher Hoskin
For reasons of my own, I need to create a Celery 4.0.2 Debian package. This means also updating the Kombu and AMQP packages. As I'm doing this work anyway, my preference would be to share it with the World through DPMT. However, I notice that python-amqp has a lot of other reverse dependancies,

Re: PyPI source or github source?

2017-03-13 Thread Thomas Goirand
On 03/13/2017 06:50 PM, Barry Warsaw wrote: > Wheels should be considered a binary release, but tarballs should still be > considered the canonical source release. For the case of PyPi releases, they are to be used using "pip install", which is what makes me think they are designed for this use

Re: I want to maintain my current packages within the team

2017-03-13 Thread Piotr Ożarowski
[Thomas Güttler, 2017-03-10] > [1]http://python-modules.alioth.debian.org/policy.html > > Yes, I accept the above policy. welcome in the team :) -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: PyPI source or github source?

2017-03-13 Thread Brian May
Barry Warsaw writes: > I've so far only encountered one package that releases on GitHub and not PyPI: > pyparted. And I've filed an upstream bug about that. I just found another one: python-ledger. Unfortunately in this case, Python packages are also bundled with the C code

Re: PyPI source or github source?

2017-03-13 Thread Scott Kitterman
On Monday, March 13, 2017 05:55:32 PM Thomas Goirand wrote: > On 03/12/2017 11:34 AM, Ghislain Vaillant wrote: > > On the other hand, I have seen very few pieces of software which had a > > *comprehensive* MANIFEST.in for generating a tarball suitable for > > packaging. The file is often either

Re: PyPI source or github source?

2017-03-13 Thread Barry Warsaw
On Mar 14, 2017, at 08:16 AM, Brian May wrote: >I just found another one: python-ledger. Unfortunately in this case, >Python packages are also bundled with the C code (libraries and client). Not entirely relevant, but pyparted also contained C code, but its mainline does support Python 3.

Re: PyPI source or github source?

2017-03-13 Thread Ole Streicher
Brian May writes: > Should we be using PyPI as our source of packages? Or github? I already had packages that use a helper to generate the version information from the git repository, and therefore need the git metadata to build from source. I could solve this with a "fake"

Re: PyPI source or github source?

2017-03-13 Thread Brian May
Scott Kitterman writes: > Like Barry, I've never had an issue with upstreams fixing their MANIFEST.in > so > that the sdist is complete when I point out the issue. I have had some people who do argue that sdist is an installation format, not a source format - if you want

Re: PyPI source or github source?

2017-03-13 Thread Ghislain Vaillant
On Tue, 2017-03-14 at 08:32 +1100, Brian May wrote: > Scott Kitterman writes: > > > Like Barry, I've never had an issue with upstreams fixing their MANIFEST.in > > so > > that the sdist is complete when I point out the issue. > > I have had some people who do argue that