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 p
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 they intend to dro
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
s
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. A
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 licens
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 d
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
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 ca
[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
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 (libraries and clien
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 abs
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.
-Barry
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" helper that
uses debia
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 the source use github.
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 sdist is an installatio
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,
in
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 notice
17 matches
Mail list logo
